ソフトウェアの品質、保守性、開発者の生産性に対するソースコードのコメントの影響に関する実証的研究はありますか？
私は、ソースコードについてコメントし、ソフトウェア製品を文書化することを提唱しています。厳密にコメントされたソースコードに取り組むことは、ソフトウェアを成長させたり維持したりしなければならなかったときに、さまざまな方法で私を助けてくれたのは私の個人的な経験と観察です。
しかし、コメントは最終的に価値がない、またはその価値が疑わしいと言う別のキャンプがあります。コメントなしのコーディングの多数の支持者は、次のように主張しています。
- コードの一部が適切に記述されている場合、それは自明であるため、コメントする必要はありません。
- コードの一部が自明でない場合は、コードをリファクタリングして自明にし、コメントが不要になるようにします。
- テストスイートはライブドキュメントです
- 時間の経過とともにコードとコメントが同期しなくなり、それが頭痛の別の原因になります
- アジャイルは、ドキュメントの山よりも作業コードの方が重要であるため、コメントの書き込みは無視しても問題ないと述べています
私にとってこれはドグマです。繰り返しますが、私の個人的な観察によると、スマートで経験豊富な開発者のチームによって作成されたソフトウェアは、最終的には自明ではないかなりの量のコードになってしまいます。
繰り返しますが、Java API、Cocoa API、Android APIなど）は、高品質のドキュメントを作成して維持したい場合、それが可能であることを示しています。
これらすべてを言っても、個人的な信念に基づいたドキュメントの賛否両論やソースコードへのコメントについての会話は、通常、うまく終了せず、満足のいく結論につながりません。
そのため、ソフトウェアドキュメントの影響、特にソースコードへのコメントが、その品質と保守性、およびチームの生産性に及ぼす影響に関する学術論文と実証研究を探しています。
あなたはそのような記事に出くわしましたか、もしあれば、それらの結果はどうでしたか？
"プログラムの理解に対するモジュール化とコメントの影響" （1981）で、ウッドフィールド、ダンスモア、シェンは、「プログラムにコメントが含まれる被験者は、コメントのない被験者よりも多くの質問に答えることができた」ことを発見しました。
ただし、 "Learning a Metric for Code Readability" （2010）では、Raymond P.L. BuseとWestleyWeimerは、コメントが読みやすさと品質に与える影響は限られていることを発見しました。
要約から：
自動化された読みやすさの尺度を構築し、...このメトリックがソフトウェア品質の3つの尺度、コード変更、自動化された欠陥レポート、および欠陥ログメッセージと強く相関することを示します...私たちのデータは、コメント自体はそれほど重要ではないことを示唆しています読みやすさのローカル判断への単純な空白行より。
12ページから：
コメントは、アノテーターの読みやすさの概念（33％の相対力）と中程度にのみ相関していることがわかりました。結論の1つは、コメントは読みやすさを向上させることができますが、通常、最初は読みにくくなったコードセグメントで使用されます。つまり、コメントと読み取り不可能なコードは効果的にバランスが取れています。正味の効果は、コメント自体が常に、またはそれ自体で、読みやすさの高さまたは低さを示すとは限らないことです。
「コメントなしのコーディング」支持者は、コメントなしのコードの方がコメント付きのコードよりも優れていると言っているわけではないことに注意してください。彼らはそれを主張している の特定のスタイル コメントなしのコード- コードをメソッドに抽出する 自己記述的な名前を使用するコード、 説明する変数を導入する 、適切なテストスイートを備えたコード-を使用するコードよりも優れているそれらのことはしませんが、コメントはあります。これは、行われた研究の適用性を複雑にする可能性があります。