リーダブルコードを読んだ

今更ながら「リーダブルコード」を読んだ。

きっかけ

職場では開発したコードをチーム内のメンバーでお互いに見せ合い、内容に問題ないかをレビューしている。 あるとき別のメンバー同士でレビューをしてる際に、「リーダブルコードに書かれているから…」という指摘でもめた。 「リーダブルコードに書かれているから」だけではそもそもどういう意味を持っているのかがわからない。 リーダブルの定義は各々によって違うはず。 そのため指摘理由にはならないと思った。 しかし、そもそも何が書かれてるのか知らないのはよくないと思い読んでみた。

自分の立場

そもそも自分の立場はチーム内に限らず社内で書かれているコード全般のレビューを担当している。

所感

コードに美しさを求め、読みやすさやメンテナンス性を向上させようという意図は概ね同意。 ただ、内容というよりは、これを読んだチームメンバーの解釈には疑問を感じた。

コメント

コードだけでは意図が伝わりにくい箇所の要約や実装理由の説明目的に使うのは良いが、とにかく何でも説明すれば良いという勢いでダラダラ書くのはよくない。 コメントがあれば多少複雑でも構わないだろう、という免罪符にはなり得ない。 13章「短いコードを書く」という意識がごっそり抜け落ちているケースが多い。 「どうコメントを書くか」よりも「どうすればコメントを書かなくて済むか」をより意識すべきだと思う。

レビューにどう適用していくか

書く側がコードの美しさに意識を置くのは良いと思う。 しかし、レビューする側がこれを強制して、これを満たしていないコードを修正させるのはそれほど良いこととは思わない。 チーム内で開発するコードに美しさを求めるのであれば、レビューされる側・する側でこの本を読むかコーディングガイドラインを作って明文化するなどして共通認識を持つ必要がある。 そうでなければ、「リーダブルじゃない」という指摘ではどう修正すれば分からないし、個人に依存する部分が強いので、感情的な対立を生んで不毛な争いになるおそれがある。

自分としては、インデントがバラバラなどよほどひどい場合であれば別だが、カンマや演算子の位置が揃ってない程度であれば、レビューで指摘はしない。 これを指摘し始めると結構キリがなくなるケースがあり、そちらに気をとられて、本来もっと大切な無駄なロジックやバグを見落として指摘が漏れてしまうから。 また、コードの整形に関して指摘する場合は、例えば「カンマの位置を揃えてください」と単に指摘するよりも、「perltidyのような整形ツールにかけてください」という指摘をするようにしている。 これは、手動でカンマの位置を揃える手間に面倒さを感じて対応してもらえないケースをできるだけ回避するのと、ツールを使ってくださいということで指摘にある程度の客観性が生まれて受け入れてもらいやすいと考えているからである。