潔癖症プログラマは面倒くさい (コメント編)
私もアラサーなので、今まで mixi なりブログなりに挑戦してきた経歴があります。
いずれも結果は3日坊主で終わりました。
何故かと言うと論理的な文章を構成するのがすごく面倒くさいからなんですよね。
なので今回のブログは、あまり推敲はせず、多少穴があってもいいので思うことをつらつら書いていく形式にしようと思います。
ここで言う潔癖症プログラマと言うのは、何か信仰 and/or 原理主義にハマっちゃった人たちをイメージしています。
などなど。
別に本人たちが勝手に自分の制約として使う分には構わないのですが、周りに押し付けてくるのがウザったいですよね。
私自身は、現実で潔癖症プログラマに出会った場合は喧嘩するのも面倒なのでテキトーに受け流します。
しかしそういう声が大きい人たちの声に流される若者がいると悲劇が連鎖しますので、おっさんの責務として反対意見を書き残そうと思います。
「コメント絶対書かない」主義について
「ソースを読んだときに、それが何をしているのか分かるように書くべきだ。そうしたらコメントなんて要らなくなるだろ。コメントを書くのは可読性が低いコードしか書けない人間の甘えだよ。さらに言えばコメントがメンテされなかった場合、そのコメントは嘘として負債になるだろ」
みたいなやつです。
実際にここまで強い言葉を使う人はほとんどいないと思いますが、まあ潔癖症の人たちはこう思ってますよね。
思ってないとしてもそう考えていると仮定します。
「ソースを読んだときに、それが何をしているのか分かるように書くべきだ」
これについては諸手を上げて賛成します。
ただこれって別に下記みたいな書き方でも達成できるわけで。
void hoge() { // DBからデータを持ってくる (数行の処理) // データをhogehogeする (数行の処理) // hogehogeしたデータをDBに入れる (数行の処理) }
他の人のブログを見ると、このように処理内容を説明している系コメントはダメコメント扱いされているのですが、個人的にはそれが不思議です。
上の例の「数行の処理」に名前を付けて別メソッドにすれば確かに自己説明的なコードになり、コメントをなくすことができます。
しかし別メソッドに分けるかどうかは、また別の基準があるべきです。
その別基準に従ってメソッドを分けた結果、そのコメントが不要になるなら消してもいいです。
しかし別メソッドに分ける基準を満たさずに1メソッドが20行超になってしまう場合は、上のようなコメントあった方が読みやすいですよ。
(私のメソッドを分ける基準は (1). 抽象化する意味があるか、(2). 複数個所で利用されるか、(3). ローカル変数の生存期間、(4). 見通しのよさ、などです。1メソッド数行信仰みたいな盲目的な判断はしていません。これについては別の機会に書きます)
「(可読性高く書けば) コメントなんて要らなくなるだろ。」
これを聞くたびに思うのが、「この人は一人でしか開発したことないのかな？」「ソースコードの書き方がたった一つしかないと思っているのかな？」です。
コメントというのは、後任者に向けた申し送り事項でもあります。
主に、なぜそのように書いたのか、意図や言い訳を伝える目的で書きます。
(a). 明確な意図を伝えるコメント
// ここで HogeParser を利用すると \ (バックスラッシュ) が読み込まれないので PiyoParser を利用する。
(b). 言い訳を伝えるコメント
// ごめん、時間がなくてハードコーディングしてしまった。
(a) も (b) も、とても有用なコメントです。
「自分が何かのコードを引き継いだときには前任者は退職していて質問できない」なんてことはザラにあります。
その時に困るのは「なぜこんな書き方をしたのか？」「これは書き直しても問題ないのか？」という疑問が生まれた時です。
読み方が分からない and/or コードを追えないのは勉強するなり時間かけて読み込めばなんとかなります。
しかし「なぜその選択をしたのか」は前任者に聞かないとわかりません。
上の (a) と (b) はその点において良いコメントになっています。
(a) は変更不可 (ただしバックスラッシュが読み込まれるようにするのであれば変更可)、(b) は気にせず変更可ということが分かりますよね。
(a) や (b) の例に挙げた意図を、コードだけで表現するのは不可能です (無理やりコードだけで表現しようとすると逆に可読性が下がる)。
「 コメントを書くのは可読性が低いコードしか書けない人間の甘えだよ」
確かに可読性が低いコードしか書けない人が安易にコメントに頼っていては可読性の高いコードを書けるようにならないかもしれませんね。
私も処理の流れが分かりやすくなるように書く訓練として「コメントを書かずにコードを書いてみる」というのは有用だと思います。
ただ仕事で書く場合、伝わるか自信がない部分があればコードを書いた後に積極的にコメントを残すべきです。
個人的な経験として、コメントがあって困ったことよりも、コメントがなくて困ったことの方が100倍多いです。
(すべてのエンジニアがそうだと思うのですが......なぜコメントを毛嫌いする人がいるのか理解できない)
「さらに言えばコメントがメンテされなかった場合、そのコメントは嘘として負債になるだろ」
コメントとやっていることが矛盾しているパターンですね。私も出会ったことがあります。
ただこれ、コメントがなかったらコードを正とするしかないんですよね。
コードの方が間違っていたらどうするのでしょう？
矛盾コメントに悩まされるのと間違ったコードに騙されるの、どちらが良いのかは私には分かりません。
しかし間違ったコメントに騙されても気づいてないので矛盾コメントを嫌うのでしょうね。
それと処理の内容をコメントとして書くのではなくメソッドに分割しているパターンにおいて、メソッド名が嘘ついてた、ということもあります。
低レベルプログラマはコメントだろうがメソッドだろうがメンテしないので、どちらにせよ矛盾したコメントやメソッド名が残るんですよね。
この場合、低レベルプログラマを雇っている会社を変えるか、自分が退職するしかないのではないかと思います。
コメント自体には罪はないので憎まないでほしいです。
まとめ
コメント書かない主義の人たちって自分たちが他の人に迷惑かけてるのを認識していないんですよね。
大体の場合において、後任者が質問したいときには既にいないので不平不満は本人には届かない。
不平不満は届かないので、本人たちは「自分はコードを書ける側の人間だ」と考えているかもしれません。
そう考えると、むしろ彼らが不憫にさえ思えてきます。
まあ一番不憫なのは申し送り事項がないコードを渡された後任者なのですが。
