Clever Geek Handbook

コードを正しくコメントする方法

コンセントの近くにラップトップを置いて観客の前に座っていたとき、そのとき隣の机でプログラミングテストが行​​われました。 私は生徒と教師が話した質問の本質を掘り下げませんでした。彼をイヴァン・イワノビッチと呼びましょう。 会話はとても穏やかで静かでしたが、私はなんとか一枚を掴みました。 先生はコメントについて話しました（プログラムは明らかに降伏しましたが、コメントは一行もありませんでした）。 この瞬間に興味があり、耳を傾け始めました。 私も興味があり、先生が即席の講義を始めたことがわかりました。 以下は、この5分間の講義で学んだ小さな知識です。



ここで説明されている多くのことは明らかなことですが、集団プログラミングの初心者（2人以上のプログラマーがコードに取り組んでいる場合）および学生にとって有用であることをすぐに警告したいと思います。 さらに、以下のすべてのヒントには代替手段があり、一部のみ使用できます。



ここで生徒を割り当てたのはなぜですか？ 彼らは、それだけで、オフセットのプログラムに取り組んでいるようです！ 教師は、プログラムを受け入れるとき、当然、2番目の開発者と見なされます。理想的には、学生の助けなしに、そこに書かれている内容とその仕組みを理解する必要があります。



コメント付きですぐにコードを書く方法




実際、その講義では、TDD（テスト駆動開発、テストによる開発）の原則がより低いレベルに移されました。 オリジナルではどのように聞こえたか覚えていませんが、本質的には「コメントでコードの構造を説明してください」 。 2つの数値を追加するプログラムコードの例（非常に誇張された理由-以下）では、この原則は次のようになります。 

int main() { //      //      //    return 0; }


そして、コメントからのフレームワークの準備ができたときにのみ、コメントで記述されているものを実装するコードを書くべきです。 

 ... int main() { double a,b; //      cin>>a; cin>>b; //     double sum = a+b; //    cout<<sum; return 0; }


前述のように、この原則は、確立されたTDDの修正された原則です。 テストのロジックからの逸脱とは対照的に、コメントからの逸脱は、コメントを書き換える必要がない限り、深刻な結果につながらないことを理解すべきです。



今、「純粋に仮説的な」状況を想像してください。優秀なプログラマー、湾曲したインド人によって書かれた200,000行のコードがすでにあり、単一のコメント行が含まれていません。 ただし、このコードを理解するためにこのプログラマを殺すだけでなく、将来的に同行する必要もあります。 あなたはこのコードを理解し、まともな人間であるため、いわば将来の世代のためにコメントを追加することにしました。 しかし、疑問が生じます。どのように？



既存のコードにコメントする方法




この質問に対する答えは非常に簡単です。親から子へのエンティティについてコメントします：クラス->メソッド->メソッド内のコード（必要な場合）。



考えることは論理的です：そしてコメントする必要のないもの。 2つの場合にコメントする必要はありません（上記のコード例が大幅に誇張された理由の1つは説明します）。



2番目の点については、少し説明して例を挙げる価値があります。100行のアセンブラCコードを挿入します。 あなたはそれを見てコメントを書きます//多くのブカフ！ ナイアシリル

その後、解雇後にあなたの場所に来た人はこのコメントを見て...それだけです！ 彼はそれを理解しようとさえしません、そして、あなたのこの記録は、それが取り除かれるまで（コードかコメントのどちらか）このコードの部分の汚名です。



最後に


結論として、コメントを書くことの芸術はプログラミングの芸術の不可欠な部分であると言えるので、コメントを書く必要があり 、それがどれほど哀れに聞こえても、高品質のコメントを書く方法を学ぶ必要があります。


More articles:


All Articles