주석 작성 및 문서화 모범 사례


20

요즘 댓글 달기가 훨씬 쉬워졌습니다. Java에는 주석을 클래스에 연결하는 멋진 기술이 있으며 Java IDE는 주석 쉘을 만드는 데 능숙합니다. Clojure와 같은 언어를 사용하면 함수 코드 자체에 함수 설명을 인수로 추가 할 수도 있습니다.

그러나 우리는 여전히 훌륭한 개발자들이 쓸모 없거나 열악한 의견이있는 시대에 살고 있습니다. 저는 제 의견의 견고성과 유용성을 개선하는 데 관심이 있습니다.

특히 Java / Clojure / Python에 관심이 있지만 언어별로 답변 할 필요는 없습니다.

주석의 유효성을 검사하고 "매끄러운"주석 (예 : 마법 번호가있는 주석, 불완전한 문장 등) 또는 잘못된 주석 (예 : 철자가 틀린 변수 등을 감지)을 자동으로 감지하는 새로운 기술이 있습니까?

그리고 더 중요한 것은 "설명 정책"이나 전략이 있습니까? 코드 작성 방법에 대한 많은 조언이 있지만 "주석 처리 방법"은 어떻습니까?

답변:


40
  • 이름은 / 문서는 당신에게 말해야 무엇을 당신이하고 있습니다.

  • 구현 방법설명 해야 합니다.

  • 의견은 왜 그렇게하는지 알려줘야합니다 .


6
당신은 왜 의견도 당신에게해야 하지 그것을 다른 방법을하고 - 즉, 중요한 디자인 선택 - 미래의 메인테이너 그렇지 않으면이 정보가 없기 때문에.

2
나는 당신이하고있는 일에 대한 의견이 여러 번 있다고 생각합니다. "왜"의견에 대한이 아이디어는 제 의견으로는 반 패턴입니다. 모든 프로그래머가 한 눈에 이해할 수있을 정도로 모든 코드를 명확하게 작성할 수 있다는 것은 신화입니다. 제 경험은 깨끗한 코드를 작성하지 않는다고 생각하는 대부분의 프로그래머입니다. "누구든지 그 기능을 수행하기 위해 함수의 코드를 읽을 수 있기 때문에이 함수의 이름을 설명 적으로 지정할 필요는 없습니다."라고 말하는 것과 같습니다. -말도 안 돼요?
dallin

2
코드가 확실하지 않은 경우 @dallin; 리팩토링을 고려하십시오. 그렇지 않으면 왜 그렇게 구현되었는지 설명하는 주석을 추가하십시오 (이는 어떻게 더 나은지를 설명합니다). 설명적인 이름과의 비교는 사과 / 오렌지이며, 설명적인 이름은 함수가 사용되는 위치를 명확하게 하며 함수 의 소스 코드에 액세스하지 못할 수 있습니다.
ratchet freak

@dallin : "모든 프로그래머가 한 눈에 이해할 수있을만큼 명확하게 모든 코드를 작성할 수 있다는 것은 신화입니다." - "누구든지 함수에서 코드를 읽어서 그 기능을 알 수 있기 때문에이 함수의 이름을 설명 할 필요는 없습니다." 하고있다!
klaar

14

이것은 논란의 여지가 있지만 가능한 한 FEW 의견을 작성하는 것이 좋습니다. 대신 깔끔하고 명확한 클래스 이름, 변수 이름 및 메소드 이름을 사용하십시오. 가능한 가장 명확한 방법으로 코드를 작성하십시오. 그리고 이것이 코드의 가장 중요한 속성이라고 생각하십시오 (요구 사항을 충족시키는 것 이외). 가능한 한 명확하게 방법을 만들었을 때만 의견을 쓰십시오. 그래도 추가 설명이 필요하다고 생각합니다.

그리고 어떤 방식 으로든 수업을 변경할 때마다 의견이 모두 올바른지 확인해야하는 조직적인 관행을 갖습니다.


1
이것은 좋은 시작이지만 OP의 질문을 만족 시키려면 자동 유효성 검사와 관련하여 실제 문제를 해결하는 무언가를 작성해야한다고 생각합니다.
Robert Harvey

2
+1-또한 코드가 작성된 이유 를 설명하기 위해서만 주석을 사용해야한다고 생각합니다 . 나는 무엇을하는지 if (a == b) then c();알지만, 왜 그렇게하는지 모른다 면-주석을 사용해야 할 때입니다. :)
Deco

데코-전적으로 동의합니다. 특정 방법이 전체 프로세스에 어떻게 적용되는지 이해하고 싶을 때 유용합니다. 다시 말해, 왜이 메소드를 호출해야하는지 또는 왜 그렇게 하는지를 설명합니다.
Dawood에는 분석 재개 모니카 말한다

작성된 코드를 명확하게하는 것 외에도 TODO 주석을 사용하여 (코드 수준) 아이디어, 생각 등을 유지해야합니다. 예를 들어 함수 / 클래스가 현재 데이터 크기를 올바르게 처리 할 수 ​​있지만 2 년 후에로드를 처리하지 못할 경우 TODO 주석을 사용하여 관찰 내용을 작성해야합니다. 미래의 개발자들은 여러분의 노력에 진심으로 감사드립니다. 코드를 작성하는 동안 별도의 txt / word 문서에서 이러한 사항을 기록하려고 시도하지 마십시오.
TechCoze


5

다른 언어에 대해서는 잘 모르겠지만 파이썬을 사용하면 자체 유효성 검사 의견의 한 형태 인 doctest 를 작성할 수 있습니다 . 물론 실제 단위 테스트 대신 사용해서는 안되지만, 명확하지 않은 특정 기능을 문서화하는 빠르고 쉬운 방법입니다. 그들은 주석이 여전히 올바른지 확인하기 위해 주석 테스트를 실행할 수 있다는 추가 이점을 제공합니다 (적어도 테스트를 포함하는 부분).


1
그리고 Sphinx는 코드와 문서를 비교하여 적용 범위 메트릭을 제공합니다.
S.Lott

3

문서를 자동으로 생성하기 위해 코드 주석을 사용하는 방법 을 찾는 가장 권위있는 위치 중 하나 는 반드시 doxygen 입니다. 그런 도구를 더 많이 얻을 수 있었지만.

이것은 문서를 자동으로 생성하기 위해 따라야하는 주석 작성 표준을 정의합니다 . 그러나 이것은 더 많은 구조를 제공하지만 의미 적으로 검증되지는 않습니다. 예를 들어 함수의 목적을 설명하기 위해 오도하는 영어를 사용했는지 확인할 수 없습니다!

이것은 주석을 구조화하는 가장 좋은 방법이지만 개인적으로 코드를 유지 관리하기 쉽게 만드는 데 더 많은 문서가 필요하다고 생각합니다. 과거에는 P.SE에 질문이있었습니다. 코드가 오픈 소스 개발자 도구의 문서가 될 수 있습니까? 얼마나 자주? 물론 이것은 오픈 소스가 아닌 프로젝트에도 적용됩니다.

코드를 유지 관리하기 쉽게하려면 코드를 처리하는 방법의 구조를 만드는 데 도움이되는 외부 문서가 있어야하며 코드 내부의 주석은 제한되어 있어야합니다.

주석 작성 정책을 정의 하려면 코딩 표준에 포함 된 전체 론적 접근 방식으로 포함시켜야한다고 생각합니다. 개발팀에 스타일 가이드와 문서를 생성하는 소프트웨어를 도입 할 때 어떤 함정있을 수 있습니까?

일반적으로 주석은 코드의 5 % 미만을 구성합니다. 실제로 코드 검토 자체는 (다른 개발 측면에 비해) 덜 주목을받는 반면 주석도 검토하기가 실제로 어렵습니다.


1
나는 마지막 문장에 동의하지 않습니다. 방금 계약을 마쳤으며, 매우 상세한 검토를 한 팀장의 도움을 받았습니다. 그의 리뷰에는 항상 의견이 포함되어 있었다-표현 방법, 변수 이름이 올바른지 여부, 미래 개발자가 알고 싶어 할 모든 정보가 포함되어 있는지 여부. 오래지 않아 나는 그가 각 의견에서 무엇을 보게 될지 알고 자신의 표준에 대한 의견을 제시 할 수있었습니다. 따라서 코드 검토를하고 코드 검토에 주석을 포함시키는 것이 조직 정책 인 경우에 발생합니다.
Dawood에는 분석 재개 모니카 말한다

이것은 일반적으로 내가 쓰는 유일한 종류의 주석입니다. 특히 들어오고 나가는 내용을 문서화하는 방법에 적합합니다 (느슨하게 입력 된 언어로 작업합니다).
DanMan

2

주석의 유효성을 검사하고 "매끄러운"주석 (예 : 마법 번호가있는 주석, 불완전한 문장 등) 또는 잘못된 주석 (예 : 철자가 틀린 변수 등을 감지)을 자동으로 감지하는 새로운 기술이 있습니까?

잘 알려진 기술이 있습니다. "코드 검토"라고하며 "pair-programming"이라는 자매가 있습니다. 여기서 "자동적으로"는 기대하지 마십시오.

그리고 더 중요한 것은 "설명 정책"이나 전략이 있습니까? 코딩하는 방법에 대한 많은 조언이 있습니다. "-어떻게 주석을 달까요?"

"Code complete" 에는 코딩 방법뿐만 아니라 "주석 달기"장, 특히 자체 문서화 코드 작성 방법에 대한 장도 포함되어 있습니다.


코드 완료시 +1 Robert Martin의 Clean Code에는 유용한 칭찬 작성에 관한 장이 있습니다. 나는 자바 세계에 대해 잘 모르겠어요하지만 .NET의 세계에서 우리는 ReSharper에서을 가지고있는 수 : 주석 코드 요소에 '자동적으로'검증 참조
MattDavey가

0

내가 즐겼던 Java의 한 가지 소스 는 Javadoc 도구에 대한 Oracle의 Doc Comments 작성 방법입니다 .

이 문서는 Sun Microsystems의 Java Software에서 작성된 Java 프로그램의 문서 주석에 사용되는 스타일 안내서, 태그 및 이미지 규칙을 설명합니다.

그리고 항목 44 : 노출 된 API 요소에 대한 쓰기 다큐 멘 테이션 코멘트 :

API를 사용하려면 문서화해야합니다. 전통적으로 API 문서는 수동으로 생성되었으며 코드와 동기화 된 상태를 유지하는 것이 번거로운 일이었습니다. Java 프로그래밍 환경은 Javadoc 유틸리티를 사용하여이 작업을 용이하게합니다. Javadoc은 일반적으로 문서 주석이라고하는 특수 형식의 문서 주석이있는 소스 코드에서 API 문서를 자동으로 생성합니다.

에서 효과적인 자바 2 판 .

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.