ストラウストラップのプログラミング入門(11) 第5章おわり
『ストラウストラップのプログラミング入門』を読む。今日は第5章の5.9からドリルまで。
この本は、いわば「実装の領域に特化して深化した『Code Complete』」なのかも。
事前条件は、コメントとコードの両方で書くのか?
5.10の最後の部分に、こういうコード片がありましてん。
int my_complicated_function(int a, int b, int c) // 引数は正であり、かつa < b < c { if(!(0 < a && a < b && b < c)) // !はNOT、&&はANDを意味する error("bad arguents for mcf"); // ・・・ }
# 2つ目のコメントは単なる文法の説明であり、こういうコメントを書けという話ではないと思いたいんだけど、どうなのかな。。。(※記事の末尾に追記)
1つ目のコメントが必要であることが意外だった。事前条件は、コメントとコードのいずれか一方でよいとばかりと思っていた。
たしかに、コメントあれば、事前条件だけを知りたいときに関数の中を読まずに済むので、ラクだ。でも、それが成立するには、コメントがコードと同期しているという前提が必要で、それにはコストがかかる。コードを変更したときにコメントがそのままになるリスクを考えると、コメントとコードで同じ事前条件を書くメリットが感じられない。もちろん、事前条件の根拠や理由をコメントに残すのは正しいと思う。
でも、世の中的には、メンテされた正しいドキュメントがそこそこ存在すると仮定するのが一般的らしいので、やはり書くべきなのかもしれない。たしかに、標準ライブラリや有名なライブラリであれば、自分もドキュメントを当てにする。
でも、OSSのツールの一部とか、たまにびっくりするほどコメントないよね?? ああいうのが現実じゃないのか・・・まあそれに対してあるべき姿というか良い習慣を示すのがこの本なのかな。そーか…。(納得した)
ドリル
覚えたこと。
そういえば、Javaのイレイジャと、C++のvector
※(2011/09/10 追記)
7.6.4「コメント」(p.200)に、次の文章があった。
プログラミング言語を知っている人にとって火を見るよりも明らかな何かを説明するコメントは避けること。(中略)本書にもこうしたコメントが含まれているが、それは読者がまだ理解していないかもしれない言語機能の使用法を説明しようとするときに限られる。
上のコード片の2つ目のコメントは、これに当たるのだろう。