以下の記事を読んで。
筆者が勤めている会社では、原則、プログラムにコメントを書かないのがルールです。人生で初めてプログラムに触れてからこのかた、プログラムには必ずコメントを書けと指導されて来ましたし、自分自身も、後輩たちにちゃんとコメント書けよと言い聞かせてきました。そんなわけで、最初に全然コメントのないソースコードの山を見たときは、正直「ゲッ、なんじゃこりゃ……」と面食らったのは確かです。
ところが、「なぜうちのプログラムにはコメントがないのか？」と同僚に尋ねてみると、実に納得の行く回答が返ってきたのでした。
なぜコメントが必要なプログラムを書くのか？
同僚いわく、「コメントが無くても読めるようなプログラムを書け」という思想が根底にあるのだそう。
適切に関数や変数が命名され、スコープがきちんと管理され、ロジックの流れが整理されているコードならば、わざわざコメントを書く必要はない。逆に言えば、処理をプログラムできれいに表現できていないからこそ、コメントが必要になってしまう。だから、うちの会社のプログラムにはコメントが無いんだよ。と、そう教えてくれました。
なるほど確かに。よく、コメントは未来の自分に向けて書くものだ、と言われます。自分の書いたプログラムを一ヶ月後に見ると、なぜこんな処理を書いたのか思い出せないということがある。そうならないようにコメントを書いておくのだ、と。しかし、自分自身ですら書いた理由を思い出せないプログラムとは、それ自体欠陥があるように感じられます。
「おまじない」「これを消すとなぜかバグる」なども同様。プログラマたるもの、自分で説明できないコードは1行たりとも書いてはいけない、と筆者は考えます。これらのコメントは、自分自身が書いたプログラムに対する責任からの逃げでしかありません。おまじないと書くくらいなら、なぜその１行が必要なのか調べて理解すればよい。これを消すなと書く前に、消されるようなコードが重大なバグを引き起こす欠陥をつきとめ、修正するべきでしょう。
プログラムそのものの質を高めるために、コメントを禁止するという考え方には、一理あるように思えます。
コメントは余計なコストを生む
コメントのもう一つの弊害は、常にメンテナンスが必要になるという点です。
ロジックの妥当性であれば、自動ユニットテストを使えばある程度は担保できます。しかし、現行処理に対するコメントの妥当性は、機械ではチェックできません。結局、人力でのメンテナンスが必要になってしまうのですね。本来、コードを書くことに使われるべきプログラマのリソースが、コメントの管理に割かれてしまうのは、生産性の低下であると言えます。
また、メンテナンスの不備によってコメントが嘘になってしまうと、大きな負債になります。コメントにはAと書いてあるけど、実際の処理内容はBだ。これはコメントが間違っているのか？ それともプログラムがバグっているのか？ 関係者に問い合わせたりドキュメントをひっくり返したりと、余計な作業がどんどん発生してしまう。こうなってしまうと、コメント無いほうがよっぽどマシだったってことになっちゃいますね。
コメントを書かない練習をしてみよう
筆者は今の会社に入社して以来、コメントを書かずにプログラムを書く修行をしておりまして、どれだけ可読性の高いコードを書けるかにはかなり敏感になりました。直感的に理解できる命名になっているか。処理の流れに不自然な部分はないか。無駄に条件分岐が増えすぎていないか。こういったことに、以前にもまして気を配るようになっています。
現在、コメントを書くのが当たり前の文化でプログラミングをしている方も、一度、コメントを書かない練習をしてみてはいかがでしょうか。今までよりも、もっとわかりやすい、簡潔なコードが書けるようになるかもしれませんよ。ではでは。