【書評】リーダブルコード

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

きっかけ

そもそも読んだのは、2014年の終わり。
ものすごい売れているので、パラパラめくったら、かなり共感できることが書かれていたので、買った。
すでに買っているのに、読了してないがために２冊買ってしまった思い出の品。
それをきっかけに、クラウドで買った本を管理するようになった。

感想・内容

読んだ感想とまとめ。
主観が入っているので、興味を持った方は購入したほうがいい。
()は、いつも通り、本にはない心の声。

コードの大原則

コードは理解しやすくしなければならない！

なぜなら、読みやすいコードは、他人が最短で理解できるコードの事だから。
他人が理解しやすいようにコーディングすることが、凡人と達人の分かれ目。

コードは短いほうがいいが、他人が理解するまで時間を短くするコードを書くことが優先。
(Javaだと三項演算子がそう。確かに使うとコードが短くなるけど、使い時を間違えると意味が分からなくなる。)

理解しやすい設計が、優れた設計。
(難しいロジックを難しいまま設計するのは、よい設計者とは言えない。)
(エンジニアの腕の見せ所は、分かり難い事をいかに分かりやすく設計するか。その一点に尽きる。)
(難しいものを難しく設計してドヤ顔するのは、恥をしらない愚か者。)

命名

名前に情報を詰め込む

明確な名前を付けることは、多くの情報を詰め込めること。
いい名前は目的や実態を表す。
名前は、短いコメントととらえるべき。

名前の長さ

スコープの範囲で決める。
スコープが狭ければ、処理が見えるため、変数名は短くていい。
(for分のインデックスに "i" を使っていいのは、スコープが狭い時だけって意味だね)

長い名前が問題ではない。意味不明な名前が問題なのだ！
(意味不明な名前とは、ようするにマジックナンバーを使ったりするやつ。)
(日本は、なぜコード値のようなものを命名したがるのだろうか？もの凄く疑問)
(大手SIは、よくすることに思える。)

誤解

誤解されにくい命名を心がける。
命名する際は、誤解を生む要因がないか、積極的に探すクセをつける。
(誤解を生むような命名にするとバグの温床になる。昼ドラで誤解を生むような会話をすると、泥沼に落ちるのと一緒)

コードの美しさ

コードの美しさは、読みやすさ。
シンプルさこそを絶対の基準にする。
美しい　＝　いい設計ではないので、注意。

美しさの原則

• 統一されたレイアウト
• 似ているところは似せる
• 関係するコードをブロック化

コードの段落表記

• 考えをグループ化できる
• 他との考えの違いを区別しやすくする
• 視覚的な踏み石
  (枕詞って言った方が日本人にはしっくりくるかな？)
  (例を出すと、熱湯風呂に入るのをためらっている奴が、「押すなよ」って言ってたら、押してあげることだ)

一貫性あるスタイル　＞　正しいスタイル
正しさよりも一貫性が重要。
見た目をそろえることが、バグの早期発見につながる。

コメント

コメントすべきこと

書き手の意図を読み手に伝える。
コメントが名前の説明になる場合、それは名前がおかしいので、考え直す。

コメントは、修正を促したり、なぜそうなったのか背景を載せるように心がける。

一般的なコメント例

TODO：あとでやるタスクを書く
FIXME：既知のバグや不具合
HACK：許容しにくい解決策
XXX：危険、問題あり

定数のコメント

なぜその値なのかを考える必要がなくすコメントにする。

コメントを書く基準

読み手が、プロジェクトを熟知していない人と考える。
つまり、コメントに書かなければいけないこととは、質問されそうなことに対する答えだ。

コメントを書く作業フロー

1. 頭にあるコメントをすべて書き出す
2. 不要な個所を探す
3. 改善、添削

コメントすべきではないこと

コードからすぐに抽出できること。
コードを補うコメント→コメントを書くのではなく、コードを修正すべき。

コメントに書くべきこと(推奨すべきこと)

• なぜこの作りになっているか
• コードの結果レベル(TODO, FIXMEなど)
• 定数の背景

読み手が欲しているもの

• 疑問に思うことを先回りして書いておく
• ファイル・クラスの全体像
• 一般的ではない動作

コメントの簡素化

コメント領域は少なくすべき。
多いコメント→それだけコードに問題がある。

歯切れのいい文書、短いけど的確な文章が、読みやすさにつながる。
特に、あいまいな代名詞は除去する。
「それ」「これ」は、読み手が何を指しているのか紐解く必要があり、手間と誤解を招く。
使ってもいいが、何を指しているのか明確にしてあげる。

ロジック

if文

条件は、否定形よりも肯定系を使う。
否定形は、分かり難さにつながる。
条件の優劣も見やすさにつながるので、注意。

三甲演算子

基本的には使うべきではないが、よりコードが簡潔になる場合は使うべき。
(これをどう使うかで、コーディング能力がわかる。)

ネスト

• 深い＝精神的苦痛を当たる
• 浅い＝理解しやすい

ネストを浅くするには、処理を途中で終わらせるようにロジックを組む必要がある。

難しいロジック

最善手ではない可能性が高い。
逆転の発想が必要になる。
巨大で難解なロジックはなるべく分割する。

変数

一度だけ初期化するもの。
変数の変更が多くなるということは、処理を追う必要があり、面倒。

テスト

テストコード

テストコードが読みやすい＝テスト以外も読みやすい。

テストコードが読みにくいと起こること

• 本物のコードの修正を恐れる
• 新しいコードを書いてもテストケース書かない

テストの原則

大切ではない詳細　→　隠す 大切な詳細　→　目立たせる

(つまり、本質ではないことは、処理を隠蔽してやる必要がある。)

テストデータ

なるべく単純化させる。
複雑なテストデータは、隠すか単純化しないと、テスト恐怖症を引き起こす。

テストやりすぎ問題

90%のテストは楽だが、残りの10%は難しいもの。
実際に100%のカバレッジを達成しても、バグがゼロになることはない。
コストとバグの消化が割りに合わなくなるので、許容店を考える。

最後に

コードの質を高める

簡単なのは、外部の視点を得ること。
外部には、６ヶ月後の自分も含まれる。
(ぼっちにやさしい！)
(自分は、触らなくなって３日立つと忘れるので、うまく利用する)

エンジニアで大切なこと

実践すること

気づく機会は、手を動かしたもののみに与えられる。
気づきがなければ、成長はできない。

他人に頼る

外部の視点は、自分に気づけないことに対する気づきを与えてくれる。
なので、指摘してくれる人は大切にすべき。

(GitHubにコードを晒す連中は、コレが主要な目的だと思う。)

感想

いろいろ考えが変わった一冊。
自分ではなく、読む人にたいしてコーディングするという考えが、一番印象にのこった＆ためになった。
意外にも、それが出来てない奴が、日本には多い。
言われたことをそのまま実装するだけでは、ダメだということを痛感できた一冊。
新人教育で読ませるだけでも価値があると思うんだが、ウチの会社は理解せんだろうな。。。

これを読書会を社内で開くことを検討中。
やって結果が出たら、ブログに書きたい。