ソースコードのコメントがソフトウェアの品質、保守性、開発者の生産性に及ぼす影響に関する実証的な研究はありますか？[閉まっている]

私はソースコードにコメントし、ソフトウェア製品を文書化することを提唱しています。私の個人的な経験と観察から、厳密にコメントされているソースコードに取り組んでいると、ソフトウェアの成長や保守が必要になったときにさまざまな方法で役立ったことがわかります。

しかし、コメントすることは最終的に価値がない、またはその価値には疑問があると言う別のキャンプがあります。コメントなしのコーディングの支持者は次のように主張しています。

• コードの一部が適切に記述されている場合、それは自明であり、したがってコメントする必要はありません
• コードが自明でない場合は、コメントを必要としないように、リファクタリングして自明にする
• テストスイートはライブドキュメントです
• 時間が経つにつれて、コードとコメントが同期しなくなり、別の頭痛の種になります
• アジャイルは、ドキュメントの山よりも作業コードの方が重要だと言っているので、コメントを書くことは安全に無視できます。

私にとってこれは単なる教義です。繰り返しになりますが、私の個人的な観察では、賢明で経験豊富な開発者のチームによって作成されたソフトウェアは、最終的に自明ではないかなりの量のコードになります。

繰り返しますが、Java API、Cocoa API、Android APIなどは、高品質のドキュメントを作成して維持したい場合にそれが可能であることを示しています。

これらすべてを言ったが、個人的な信念に基づいたドキュメントの長所と短所およびソースコードへのコメントについての会話は、通常うまく終了せず、満足のいく結論につながらない。

そのため、ソフトウェアドキュメントの影響、特にソースコードのコメント、品質と保守性、およびチームの生産性への影響に関する学術論文と実証研究を探しています。

そのような記事につまずいたことがありますか、もしあればその結果はどうでしたか？

で、「モジュール化し、プログラム理解のコメントの影響」（1981）、ウッドフィールド、Dunsmore、とシェンは「被験者そのプログラムはコメントはコメントのないものよりも多くの質問に答えることができました含まれている。」ことがわかりました

しかし、「コードの読みやすさの測定基準の学習」（2010）で、Raymond PL BuseとWestley Weimerは、コメントが読みやすさと品質に限定的な影響しか及ぼさないことを発見しました。

要約から：

自動化された読みやすさの尺度を構築し、...このメトリックがソフトウェア品質の3つの尺度と強く相関していることを示します：コード変更、自動欠陥レポート、および欠陥ログメッセージ...データ自体は、コメント自体の重要性が低いことを示しています単純な空白行よりも、ローカルでの読みやすさの判断まで。

12ページから：

コメントは、アノテーターの読みやすさの概念と比較的よく相関しているだけであることがわかりました（33％の相対出力）。1つの結論として、コメントは読みやすさを高めることができますが、コメントは通常、読みにくくなったコードセグメントで使用されます。コメントと読みにくいコードは効果的にバランスが取れています。正味の効果は、コメント自体が必ずしも読みやすさの高低を示すとは限らないということです。

「コメントなしのコーディング」支持者は、コメントなしのコードがコメント付きのコードよりも優れていると言っていないことに留意してください。彼らは、コメントのない特定のスタイルのコード- 自己記述的な名前のメソッドにコードを抽出するもの、説明変数を導入するもの、優れたテストスイートがあるもの-をしないコードよりも優れていると主張していますしかし、コメントがあります。これは、行われた研究の適用性を複雑にする可能性があります。