第1部 表面上の改善 ~コメントの付け方Vol.3~
前回に引き続き、コメントの付け方をさらに分析してみた。
自分の考えをコメントにする
コメントは、コードを書いている時に考えていた課題や意図、TODOをコメントにすべきとのこと。見てわかることは書く必要がない。
確かに、プログラムは一度作ったら終わりではなく改修/保守していく。その時になぜこのコードを書いたかがわかれば、エラーの原因特定やチューニングの助けになる。自分だけでなく他の人の役にも立つことだから取り入れていこう。
読む人が驚くポイントにコメントをつける
パッと見では伝わらないコードはコードを直すべきだが、直しても伝わりにくいコードはどうしても出てくる。その時はコメントで説明しよう、ということだが、客観でコードを見ないといけないからなかなか難しそうだ。
コメントどうこうより、客観でコードを見る力が不足している気がするので、そっちの方が優先だな。
情報密度の高いコメントをつける
例えば、以下のようなコメントがあったとしよう。
// このクラスには大量のメンバがある。同じ情報はデータベースにも保管されている。但し、
// 速度の面からここにも保管しておく。このクラスを読み込むときには、メンバが存在してい
// るかどうかを先に確認する。もし存在していれば、そのまま返す。存在しなければ、データベー
// スから読み込んで、次回のためにデータをフィールドに保管する。
こうではなく、以下のように書けばいい。
// このクラスの役割は、データベースのキャッシュ層である。
引用元:Dustin Boswell, Trevor Foucher『リーダブルコード』オライリー・ジャパン出版
慣れ親しんだ言葉を使うことで文章を単純化するのは必須だな。長くてくどいと読んですらもらえないだろうから。
そのためには情報密度の高い言葉を扱えるよう、本を読んだり人と会話をして語彙力をつけないといけないな。ゴリ力ならあるんだけどね。
この記事が気に入ったらサポートをしてみませんか?