はじめに

『リーダブルコード』を久しぶりに読みました。

[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

リーダブルコードより良いコードを書くためのシンプルで実践的なテクニ（Theory　in　practice） [ ダスティン・ボズウェル ]
価格：2640円（税込、送料無料) (2020/8/24時点)

楽天で購入

まだエンジニアになったばかりのときに一度読みましたが、最近新人に対してコードレビューをする機会が増えてきたので自分の知識の整理のために再度読んでみることにしました。

やはり名著で読む度に学びがあるので、今回学んだことをまとめておこうと思います。

似ているコードは似ているコードに見せる

似ているコードは、ちゃんと改行位置や変数定義の位置などを揃えておくことで読み手に「あのコードと似ている」ということを伝えることでより読みやすいコードになるということがあると思います。

普通に書いていれば特段難しいことはないので似せて書くというのは実現できますが、厄介なのは Lint に自動で直される場合です。

例えば一行が長くなりすぎると Lint は自動で改行してくれますが、似ているロジックが並んだコードで片方は改行されているが、片方は改行されていないということがあると、コードのシルエットが変わってしまうことでぱっと見「似ている」ということが読み手に伝わりません。

こういったときにちゃんとリーダブルなコードを書くために、他の場所のちゃんと改行して似ているコードはちゃんと似せて書くことは意識しなければならないなと思いました。

「合理性」と「一貫性」

A という書き方と B という書き方があったときに、どちらかと言えば A の書き方の方が合理性がありそうだが、すでにチーム内では B という書き方で統一されたときにどちらの方法で書くかというのは少し迷うところだと思います。

例えば私のチームであったのは、「Emotion」という CSS in JS のライブラリを使っているのですが、このライブラリには StyledComponent の書き方が 2 通りあります。

const Section = styled.section({
  backgroundColor: #333;
  color: #fff;
})

const Section = styled.section`
  background-color: #333;
  color: #fff;
`

上の書き方は backgroundColor のようにキャメルケースで書いていますが、下の書き方は background-color のようにハイフンケースで書いています。

Emotion のドキュメントを読む限り、どちらの書き方が推奨されている訳でもないので、どちらで書くかはチームの好みの問題になります。

私のチームではフロントは基本的に全てキャメルケースで統一されていたので、新しく emotion を導入する際も上の書き方を選択しました。

しかし、後から join したメンバーが「これはこのチームに関して言えば明確に下の書き方の方が良い。何故なら、既に css ファイルに css を書いているところを CSS in JS で StyledComponent で書き直すというタスクがいくつか発生しているので、下の書き方にしておいた方がコードをコピペするだけでタスクが完了する。」と主張しました。

これに対して全メンバーその通りだと判断して、下の書き方で出された PR も approve するようになってしまいました。

その結果、全体で StyledComponent の書き方が統一されておらず、また後から入ってきたメンバーにとっては「何故書き方が統一されていないんだ？何か理由があるのか？」と読みにくいコードになってしまいました。

ここでの反省としては、どちらかと言えば合理的な書き方である下の書き方は一旦 reject して一貫性を優先する、その後書き直した方が良いという結論になれば一気に書き直す、そこまでする必要がないのであれば放置、というようにすれば良かったなと反省しました。