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

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

コードは他の人が再短時間で理解できるように書かなければいけない

時間やバイト数のように計測できるものであれば、
変数名に単位を入れるといいだろう

スコープ（その名前が「見える」コードの行数）が小さければ、
多くの情報を詰め込む必要はない

名前を決める前に反対意見を考えるなどして、誤解されない名前かどうかを
想像してみよう。最善の名前というのは、誤解されない名前である

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

コードを「段落」に分割する

一貫性のあるスタイルは「正しい」スタイルよりも大切だ

コードからすぐに分かる事をコメントに書かない

優れたコード　＞　ひどいコード＋優れたコメント

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

ハマりそうな罠をコメントで告知する

入出力のコーナーケースにコメントで実例を記載する

コードの意図を書く

（if文）単純な条件を先に書く

（if文）関心を引く条件や目立つ条件を先に書く

無関係の下位問題を積極的に見つけて抽出する
・関数やコードブロックを見て「このコードの高レベルの目標は何か？」と自問する
・コードの各行に対して「高レベルの目標に直接的に効果があるのか？
　あるいは、無関係の下位問題を解決しているのか？」と自問する
・無関係の下位問題を解決しているコードが相当量あれば、それらを抽出して別の関数にする

理想とはほど遠いインターフェースに妥協する事はない

自分でラッパー関数を用意して、手も足も出ない汚いインターフェースを覆い隠す

プロジェクト固有のコードから汎用コードを分離する

コードを改善するには、タスクを別々の領域に分割すればいい

読みにくいコードがあれば、そこで行われているタスクを全て列挙する。
そこには別の関数（またはクラス）に分割できるタスクがあるだろう

おばあちゃんがわかるように説明できなければ、
本当に理解したとは言えない

・コードの動作を簡単な言葉で同僚にもわかるように説明する
・その説明の中で使っているキーワードやフレーズに注目する
・その説明に合わせてコードを書く

プロジェクトが成長しても、コードをできるだけ小さく維持するしかない
・汎用的な「ユーティリティ」コードを作って、重複コードを削除する
・未使用のコードや無用の機能を削除する
・プロジェクトをサブプロジェクトに分割する
・コードの「重量」を意識する。計量で機敏にしておく。

プログラマというのは、既存のライブラリで問題を解決できる事を知らない事が多い

たまには標準ライブラリの全ての関数・モジュール・型の名前を15分かけて読んでみよう

テストコードというのは「本物のコードの動作と使い方を示した非公式的な文書」

他のプログラマが安心してテストの追加や変更ができるように、
テストコードを読みやすくする

テストコードがわかりにくいと、
・本物のコードを修正するのを恐れる
・新しいコードを書いたときにテストを追加しなくなる

テスト
・テストのトップレベルは出来るだけ簡潔にする。入出力のテストコードは
　1行で記述できるといい
・テストが失敗したらバグの発見や修正がしやすいような
　エラーメッセージを表示する
・テストに有効な最も単純な入力値を使う
・テストに関数に説明的な名前をつけて、何をテストしているのか明らかにする

外部の視点を得るというのは、コードが「ユーザフレンドリー」かどうかを
確認する優れた手段である