소스 코드 주석 처리가 소프트웨어 품질, 유지 보수성 및 개발자 생산성에 미치는 영향에 대한 경험적 연구가 있습니까? [닫은]

나는 소스 코드에 대해 의견을 말하고 소프트웨어 제품을 문서화하는 것을 옹호합니다. 필자가 언급 한 소스 코드 작업은 소프트웨어를 키우거나 유지해야 할 때 다른 방식으로 도움이되었다는 것이 개인적인 경험과 관찰입니다.

그러나 논평은 궁극적으로 가치가 없거나 그 가치에 의문을 제기하는 또 다른 캠프가 있습니다. 의견을 제시하지 않은 수많은 코딩 지지자들은 다음과 같이 주장합니다.

• 코드 조각이 잘 작성된 경우 자체 설명이 필요하므로 주석을 달 필요가 없습니다.
• 코드가 설명이 아닌 경우 리팩토링하여 설명이 필요하지 않으므로 설명이 필요하지 않습니다.
• 테스트 스위트는 실제 문서입니다
• 시간이 지남에 따라 코드와 주석이 동기화되지 않아 두통의 또 다른 원인이됩니다.
• 애자일은 작업 코드가 문서 더미보다 중요하므로 주석 작성을 무시해도 안전합니다

나에게 이것은 단지 교리입니다. 다시 말하지만, 저의 개인적인 관찰은 똑똑하고 숙련 된 개발자 팀이 작성한 소프트웨어는 궁극적으로 자명하지 않은 상당한 양의 코드로 끝납니다.

다시 말하지만 Java API, Cocoa API, Android API 등은 양질의 문서를 작성하고 유지하려는 경우 가능하다는 것을 보여줍니다.

이 모든 것을 말하면서, 문서의 장단점에 대한 대화와 개인적인 신념을 기반으로 한 소스 코드에 대한 주석은 일반적으로 잘 끝나지 않으며 만족스러운 결론을 내리지 않습니다.

따라서 저는 소프트웨어 문서, 특히 소스 코드 주석, 품질 및 유지 관리 성 및 팀 생산성에 미치는 영향에 대한 학술 논문과 실증적 연구를 찾고 있습니다.

그러한 기사를 우연히 발견했으며 그 결과는 무엇입니까?

에서 "모듈화 및 프로그램의 이해에 대한 의견의 효과" (1981), 우드 필드는 Dunsmore, 그리고 쉔은 "그 프로그램 과목 댓글 댓글이없는 것보다 더 많은 질문에 대답 할 수 있었다 포함되어 있습니다."발견

그러나 "코드 가독성을위한 메트릭 학습" (2010)에서 Raymond PL Buse와 Westley Weimer는 주석이 가독성과 품질에 미치는 영향이 제한적이라는 사실을 발견했습니다.

초록에서 :

우리는 자동화 된 가독성 측정을 구성하고이 메트릭이 소프트웨어 품질의 세 가지 측정 값, 즉 코드 변경, 자동화 된 결함 보고서 및 결함 로그 메시지와 밀접하게 관련되어 있음을 보여줍니다. 데이터에 따르면 주석 자체는 덜 중요합니다. 가독성에 대한 현지 판단에 대한 단순한 빈 줄보다.

12 페이지부터 :

의견은 주석 작성자의 가독성 (33 % 상대 검정력) 개념과 중간 정도의 상관 관계가있는 것으로 나타났습니다. 한 가지 결론은 주석이 가독성을 향상시킬 수 있지만 일반적으로 주석이 잘 읽히지 않는 코드 세그먼트 (주석과 읽을 수없는 코드가 효과적으로 균형을 잡는 부분)에서 사용된다는 것입니다. 순 효과는 주석 자체가 항상 가독성이 높거나 낮은 것을 나타내는 것은 아닙니다.

"코멘트없는 코딩"지지자들은 코멘트가없는 코드가 코멘트가있는 코드보다 낫다고 말하는 것은 아닙니다. 그들은 주석이없는 특정 스타일의 코드 ( 자체 설명 이름이있는 메소드 로 코드를 추출하는 코드 , 변수를 설명 하는 코드, 테스트 스위트가 좋은 코드)가 그 일을하지 않는 코드보다 낫다고 주장합니다 그러나 의견이 있습니다. 이로 인해 수행 된 모든 연구의 적용 가능성이 복잡해질 수 있습니다.