「リーダブルコード」

「リーダブルコード」で気になった部分の抜粋

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

1. 理解しやすいコード

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

2. 名前に情報を詰め込む

• 値の単位
  • 時間やバイト数のように計測可能な値であれば、変数名に単位を入れるといい
• スコープが小さければ短い名前でもいい

3. 誤解されない名前

• 最善な名前とは誤解されない名前である
  • コードを他人が読んだときに意図を理解できるということ
• 単語に対するユーザの期待にも注意する必要がある
  • get()やsize()というメソッドがあれば、それらは軽量なメソッドであることが期待されている

4. 美しさ

• すぐれたソースコードは「目に優しい」ものでなければならない
• 読みやすくする３原則
  • 読み手が慣れているパターンと一貫性のあるレイアウトを使う
  • 似ているコードは似ているように見せる
  • 関連するコードをまとめてブロックにする

5. コメントすべきことを知る

• コードからすぐわかることをコメントに書かない
• コメントはひどい名前の埋め合わせに使うものではない
  • 優れたコメントよりも名前の方が大切
  • 優れたコード > ひどいコード + 優れたコメント
• 関数やクラスを文書化する時には、「このコードを見てびっくりすることは何だろうか？どんな風に間違えて使う可能性があるだろうか？」と自分に問いかける

6. コメントは正確で完結に

• 複数のものを指す可能性がある「それ」や「これ」などの代名詞を避ける

7. 制御フローを読みやすくする

• if文で使用する条件は否定形よりも肯定形を使う
• 三項演算子を使って強引に行数を少なくするよりも、他の人が理解するのにかかる時間を短くする
• 関数から早く返す
  • ガード節を導入する（関数で複数のreturn文を使ってないけないと思っている人がいる。アホくさ）
• ネストを浅くする
  • コードのネストが深いと読み手は「精神的スタック」に条件をプッシュしなければならない。 閉じ括弧を見てスタックからポップしようと思っても条件がなんだったか思い出せない
  • （ネストを増やさないようにするために）変更するときにはコードを新鮮な目で見る。一歩下がって全体を見る

8. 巨大な式を分割する

• 人間は一度に３～４のものしか考えられない。つまりコードの式が大きくなるとそれだけ理解が難しくなる
• 「頭がいい」コードに気を付ける。あとで他の人がコードを読むときにわかりにくくなる。

9. 変数と読みやすさ

• 変数が多いと変数を追跡するのが難しくなる
• 変数のスコープが大きいとスコープを把握する時間が長くなる
  • 変数のことが見えるコード行数をできるだけ減らす
• 変数が頻繁に変更されると現在の値を把握するのが難しくなる
  • 「永続的に変更されない」変数は扱いやすい
  • イミュータブルはトラブルになる傾向が少ない

10. 無関係の下位問題を抽出する

• 関数やコードブロックを見て「このコードの高レベルの目標は何か？」と自問する
• 関数は小さく独立していれば機能追加がしやすく可読性が高い
• 「理想とは程遠いインターフェースに妥協することはない」
  • 自分でラッパー関数を用意して汚いインターフェースを覆い隠す
• グルーコード（他のコードを支援するためだけに存在するコード）はプログラムの本質的なロジックとは関係ないことが多い
• プロジェクト固有のコードから汎用コードを分離する
  • 一般的な問題を解決するライブラリやヘルパー関数を作ると、プログラムに固有の小さな核だけが残る

11. 一度に１つのことを

• 一度に複数のことをしているコードは理解しにくい
  • たとえばオブジェクトを生成し、データをきれいにして、入力をパースして、ビジネスロジックを実行するようなコード
• 読みにくいコードがあれば、そこで行われているタスクをすべて列挙する
  • 他の関数に分割できるタスクは分割する
• 一番難しいのはプログラムが行っていることを説明することである

12. コードに思いを込める

• 誰かに複雑な考えを伝える時には、細かいことまで話しすぎると相手を混乱させる
  • 自分の考えを凝縮して最も大切な概念にすることが必要になる
• プログラムのデバッグに悩んだときは、問題を声に出して説明するだけで解決策が見つかることがある。

13. 短いコードを書く

• もっとも読みやすいコードは何も書かれていないコードだ
• あらゆる協調システムは成長するし、それらを結び付ける複雑さはもっと速い速度で成長する
  • プロジェクトが成長してもコードをできるだけ小さく軽量に維持することが重要
• 未使用のコードは削除する
• プログラマは既存のライブラリで問題解決できることを知らないことが多い
• ライブラリの再利用はなぜいいのか？
  • 成熟したライブラリのコードの裏側には莫大な設計・デバッグ・修正・文書・最適化・テストが存在する

14. テストと読みやすさ

• テストコードは「本物のコードの動作と使い方を示した非公式な文書」と考える人もいる
• 他の人が安心してテストの追加や変更ができるようにテストコードを読みやすくする
• テスト関数の名前は長くなっても構わない
  • テスト関数の名前はコメントだと思えばいい。名前は説明的な方がテスティングフレームワークで役に立つ場合がある
• テストに優しい開発
  • テストしやすいコードには、明確なインターフェースがある。状態やセットアップが無い。検査するデータが隠されていない。
  • テストに優しい設計をすれば、ふるまい毎にうまく分割されて自然にコードが構成されていく
  • 「これはテストが難しそう」と思ったら、立ち止まって設計を考え直せばよい
• テスト容易性の低いコードとそこから生じる設計の問題

特性	テスト容易性の問題	設計の問題
グローバル変数を使っている	グローバルの状態をテストごとに初期化する必要がある（テスト同士が干渉してしまうため）	どの関数にどんな副作用があるのかわかりにくい。関数を個別に考えることができない。プログラム全体を把握しなければならなくなる
多くの外部コンポーネントに依存している	最初に足場を設定しなければならないので、テストを書くのが難しい。みんなテストを書こうとしなくなる	依存しているものが落ちるとシステムが使えなくなる、システムが考えなけれなならない故障状態や回復経路が増える
コードが非決定的な動きをする	テストはあてにならず信頼できない。テストが正常に動かない場合があるので無視されるようになる	プログラムを論理的に判断できなくなる。バグを追跡したり修正したりするのが非常に難しい「リーダブルコード」についてのまとめ

---

関連エントリ