とあるプロジェクトに参画した時、リードコーダーからドキュメントコメント（メソッド/クラス上部に書くコメント）以外でコメントを書くことを禁止されました。そのリードコーダーは独裁的ではありましたが、プログラミングに関しては相当出来る人で当然指示に従いました。

ソースコード中にコメントを書くか書かないかは意見が真っ二つに割れる問題だと思います。コメントを書かない勢の言い分としてよく上がるのが

「そもそもコメントがないといけないようなソースコードは書くべきではないし、改善の余地がある。変数名もきちんとついていないのでは？」

「ソース修正に伴いコメントも直す必要があるのでメンテナンスが大変」

「ソースが見づらくなる」

というものが多いと思います。実際上記のような理由でコメントを書くなと言われました。それと当時の開発はC#でVisual Studioで行っていたのですが、ドキュメントコメントをきちんと書いているとソース上にカーソルをあてるとメソッドのコメントが見れるので確かにわざわざコメントを書かなくても十分わかると思いました。

実際にコメントを書かなくなって

見るソースは当然コメントがありません。当時は設計書も薄く仕様を把握するにはソースしかありません。ということはソースを必死に読み込む必要があります。デバックをしてひとつずつ動きを確認し、わからない関数や書き方は都度調べることになります。

そんなことを数カ月も続けていると自然と知識がついてきます。最初はひどい書き方をしていたものですが、改修が入るタイミングでリファクタリングをするようになり、変数名は今まで以上にとても気をつかうようになりました。読むのはソースしかないため、より動きを把握できたような気がします。

さらに無駄なコメントがないほうがソースが見やすいです。コメントはIDE上ソースとして扱われないため、例えば//の後ろにスペースを入れるのか、半角スペースか、全角スペースかなどその辺も合っていないとよけい見づらくなってしまいます。

そもそもコメントが間違えていることもあったり、日本語コメントを読んでも何を言いたいのかわからなかったり、　var sum = “”; // 合計　みたいになっていたりコメントを考えるのも大変です。

また人によって「ですます」口調だったり「。」で終わっていたりいなかったり、統一性がなくなんか嫌だなーと思っていたのですが、コメントを書かなくなることでそういったことがなくなりました。

コメントがないとソース解読に時間がかかってしまう？

プロジェクトの状況にもよると思いますが、本来ソースを解読するのは時間がかかってしまうものだと割り切って時間をかけていいと思います。

大袈裟な例を言えば大してソースを解読せずコメントを信じて実装するというほうがよっぽど危ないしトータルで時間もかかってしまいます。

もしかしたらレビューをする上司がプログラムをよくわかっていないためコメントを書かなければいけないというのであれば本末転倒な気がしますしレビューをその人にされる意味もないと思います。は対面でするのであれば口で説明をすればいいと思いますし…。

今後もコメントは書かないと思います

新人の頃に読んでいたテキストには適切なコメントを書こうと書いてあります。そうやって勉強してきたのでコメントは「書くもの」と思い込んでいました。ただ、「書かなくてもいい」という選択肢もあります。

今後のプロジェクトでコメントは書くようにと指示されることもあると思います。そういう時は書こうと思いますが、特に指示がなければいちいちコメントは書かないです。

経験を積んでいくうちに考え方は変わるかもしれませんが、今はそう思います。