題名のとおり、リーダブルコードを読んで、今すぐ取り入れたい（取り入れなきゃ…）と私が感じた部分をまとめてみました。

リーダブルコード

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

プログラミングをする人なら、だれでも一度は聞いたことがある本だと思います。
固くならない読みやすい書き方で「コードはこう書いたらいいよ」というのを教えてくれる良書です。

1,「一時的な保管」しか役割がない変数への命名は、tmpでも〇

情報を一時的に保管するために変数を用意する場面が出てくると思いますが、どういう風に命名すればいいのか悩んだことはないでしょうか？（私は悩んでました）

本書では、

その変数には情報の一時的な保管以外役割がない
その変数の生存期間がわずか数行である
ほかの関数に渡されたり、何度も書き換えられたりしない

の場合、tmpという変数名をつくことは問題ないと教えてくれています。

2, get*() というメソッド名は誤解を招く可能性あり

getで始まるメソッドは、メンバの値を渡すだけの「軽量アクセサ」であると暗黙に認識していることが多いです。
なので、例えば、DBからデータを取ってきて計算処理をしてその値を返すようなメソッドで、そのメソッドの実行コストが高い場合、get*()と命名してしまうのは危険な可能性があります。

本書では、

コストの高さが事前にわかるように、メソッド名をcomputeXxx()にする
そもそもコストがかからない実装にする

のが適切だろうと説いています。

私自身も、getと付くメソッドは、メンバの値を渡すだけのシンプルなもの、と暗黙に認識していたのですが、特に何も考慮しないでget*()というメソッド名を作成していたので反省です...。

3, コードの欠陥にコメントをつける

自分が書いたコードに欠陥があると公表することになるので、できればやりたくない・恥ずかしいことだと思ってしまいますが・・・。
開発は大体チームで行うものですし、たとえ自分ひとりだったとしても、数カ月前に自分自身で書いたコードでも「なんだっけ・・・」となるので、やはり改善が必要な時は記載するのが◎です。

記法	典型的な意味
TODO:	後で手を付ける
FIXME:	既知の不具合があるコード
HACK:	あまり綺麗じゃない解決策
XXX:	危険！大きな問題がある

4, 条件式の引数の並び順を決める際は、左側に「調査対象」を持ってくる

下記のコードの場合、(1)より(2)の方が読みやすいと思います。

example.java

// (1)
if(length > 10)

// (2)
if(10 < length)

ここで判定したいのは、「length」が10より大きいかどうか、なので、調査対象である「length」を左側に持ってきた方が〇です。

これは本書を読む前から実践していたことですが、(2)の書き方も見たことがあったので、本書を読んで改めてこれでよかったのだと確認できました。

5, 無関係の下位問題を抽出する

「無関係の下位問題」という言葉になじみがないのでどういうことかわかりにくいと思います。
下記ブログの解説がわかりやすかったので、まずここを読んでみると理解が進むかと思います。

【リーダブルコード】無関係な下位問題を抽出するってどういう意味？

私なりに解説すると、「解決したい本質的な目的（これが上位問題）を達成するために必要になること（これが下位問題）は、別の関数に切り出そう。そうすればその切り出した関数は将来的に再利用可能になるし、上位問題に集中することができる」
ということです。

また、各コードが小さく独立していれば、各々のコードの改修のしやすさや読みやすさも向上します。

6, テストコードにはヘルパー関数を作成して、重要ではない詳細を目立たなくする

テストするときには、対象をテストするために設定や準備などが必要になると思いますが、それらをテストコードの中に書いてしまうと、重要ではない部分が大きくなって見通しが悪くなります。
なので枝葉となる詳細部分はヘルパー関数に切り出し、実際のテストコードは最小にとどめておくのが〇です。

（私は詳細を他の関数に切り出す、という作業を億劫がってテストの中に直接書いてしまう場面があったので・・・耳が痛いです）

過不足のないテストコードを書くということは、時には実装するときよりも考えなければならないことがあったりと難しいものだと思います。（私自身もちゃんと書けているのかどうかいつも不安・・・）
本書に書かれてあることを指針にテストも書いていきたいです。

終わりに

読みやすいコードを書きたいと思っていても、具体的にどう書けば読みやすくなるのか、ということを習得するのは、特に個人開発や独学しているとコードレビューいただける機会があまりないので、なかなか難しいと思います。
本書は目から鱗のような新しいことは書いてなく当たり前のことが書いてありますが、その当たり前を普段から実践することが大事なのだと思います（これは自分に言い聞かせている…）
読みやすい書き方で指南してくれているので、是非一読はしておきたい書籍だと思います。
（私もさらっと読んだだけなので手元に置いておいて何度も読み返すようにしたいです）