なんでもかんでもコメント書けばいいわけじゃない。
見ればわかるじゃん、ていうことまで書く必要はない。
でもそのさじ加減は、少し経験を積まないと、わからない。
それは言葉にしてもなかなか伝わらない、・・・ように思える。
コメントがいるってことは、
シンボル名（関数、変数、マクロ、...）が 単なる記号にしか見えてない ってことで、
だからコメントを書いて説明しようとするのである。
シンボル名が「ちゃんと意味があって読める」ものになっていない、
プログラムがまだ文章になりきっていない、ということだ。
メソッドの名前を「読めば」、これは「〇〇を〇〇する」ってわかるように書いてないと。
自分でそう思えるようにならないと、このニュアンスが体得できたことにならなくて。
例えば、fopen() の前に「ファイルを開く」って書いてあっても、ぜんぜんうれしくない。
「見ればわかる」でしょ。
どうしても「コメントを読んで」コードを理解しよう、ってなってしまう。
コメントのほうが読みやすいから仕方ないかもしれないけれど。
だから、読んでわかる名前にしないと。
ただ、その名前が他のひとに伝わるか、ってところも難しいけれど。
コメントの書き方の第一歩として、
詳細設計書のままをまずは書き写して、その下にコードを書いていく、
みたいのもある。
逆に言って、詳細設計書と同じようなことを書く、って言ってみたりする。
これはこれでいいと思う。
そのときに「ファイルを開く」の下に fopen() があってもこれは仕方のないことだ。
これがそのうち場合によっては目障りに思う、っていう習熟度が必要なのだと思う。
だけど、「コメントをうまく書けること」と「動くプログラムが書けること」は別の技術であるわけで。
人間にはうまく伝わらなくても、コンピュータさんに伝わればいいんだから。
だから、コメントのことは「置いといて」でいいのかも、とも思う。
ただ、コードがバグってることもあるので、
ここはどうしたかったのか、意図は書いててほしいかも。
仕様書に書かれていない、細かなエラー系処理などは特にそう。
コード自体がかなり難解なときもあるので。
こんなときはコメントだいじなのである。
