コメントには、多くの意見があった（なんて皮肉な）
投稿がありましたが、
最良のコードは自己文書化などです。
一般的に、私は第一人者のふりをせず、自分の意見だけを述べています。 最良のコメントはそこにはなかったが、実際的な議論を含んでいるという意見とは異なります。
投稿では、開発で10年間コメントを使用している方法を簡単に説明し、ドキュメントの一般的なトピックにスムーズに触れます。
コメントは、忘れたコードを見つけるのに役立ちます。
Artemy Lebedev（衝撃的なIMHOのマスター）にはそのようなルールがあります-彼は彼の考え方を知っています。 また、たとえば、目的の写真がある場所などを忘れた場合、分類システムを知っていると、適切な写真をすばやく見つけることができます。
コメントについても同じです。 私は長年触れていないプロジェクトがあります。
IDEでこのプロジェクトを開き、いくつかの単語を入力して、簡単に必要なファイルとクラスを見つけます。 つまり、最初のトピックは、少なくともすべてのファイルの動作を最初から記述することです。 検索時間を大幅に節約できます。 また、テストもある場合-検索は完全に簡素化されます。
コメントはIDEでの開発に役立ちます
IDEは、あらゆる種類のjavadocを念頭に置いて配置されています。
そして、新しいコードを書くとき、ツールチップは何をどのように説明するかを非常に簡単にします。 特に、チームがプロジェクトに取り組んでおり、サードパーティの方法を使用している場合。
コメントはドキュメントの作成に役立ちます
私はあなたのことは知りませんが
、参照としてコメントから生成されるドキュメントが常に好きでした
。 何かを設計しているときに、コード全体を開かずに、外部ライブラリの特定のメソッドを見ると本当に便利です。
一般的なドキュメント
一年後、私は「怠lazは進歩のエンジンだ」という言葉が好きになり始めました。 怠け者のプログラマーまたは管理者は、生得的で有用な品質だと思います。
怠inessによって、同じ作業を有限回数以上行わないという直感的な欲求を理解します。 たとえば、Apacheを3回調整した場合、4番目の優れた管理者が問題の本質を取り除くか、プロセスを自動化します。 または、5台のサーバーで右利きの構成を行う4回目に、サーバーに自動構成を注ぎます。 この品質がなければ、管理者は毎回ルーチンを実行します。
開発者の質問が非常に頻繁に行われるいくつかのロードされたプロジェクトが与えられたとき、3本の釘の原則を適用し始めました。
3番目の質問ごとに、典型的な質問ごとにFAQを作成し、各タスクのチュートリアルコードにコメント付きのチュートリアルを作成しました。6か月後、チュートリアルとFAQへのリンクで80％を回答し、ストリームを離れませんでしたが、プロジェクトの部下の数は2から5に増加しました。
おわりに
単独で作業する場合、時間が長い場合、工業規模でプロジェクトを行わない場合は、美しい自己文書化コードを記述できます。 とりあえずこれを自分のクラフトでやった。
読みやすいコードを書くことはできますが、コメントはプロジェクト全体を理解し、上記の実用的な問題を解決するのに役立ちます。チームで作業している場合、プロジェクトは100,000行を超えるコードに成長し、数年後にはそれらに戻ります。コメントが必要なだけです。 少なくとも、このファイルまたはそのファイルが行うことのレベルで、これまたはその大きな重要なロジック。
そしてもちろん、
Dannig-Krueger効果を忘れないでください。
人は自分のコードを読みやすく、理解できると考えることができますが、これは他の人にとってそうであるという事実ではありません。自己文書化コードについてMcConnellを読んでコメントを書く必要がないことを覚えており、コード設計やコード規則に関する他のすべての推奨事項を無視
した初心者からプロジェクトを受け入れた後は特に重要です。サイト）。
同時に、あなたがシニアのチームリード開発者であり、あなたの責任が非技術者との仕事、または新規参入者との仕事を含む場合、ドキュメントは、いわば、キャッシュヒットraio、時間を大幅に節約できます。
トピックへのリンク
1.
自己文書化コードのようなものはありません-それは神話です2.
肥大化した名前と自己文書化コードの神話3.
意図とアクション、または自己文書化コードの神話4.
自己文書化コードとその他の神話