自分がコードを書くときに気をつけたいこととしての、目次的なメモです。
ある程度コードに慣れたすべてのプログラマーは、読むべき本だと思います。
本にはもっと具体的な書き方が書いてあるので、ぜひ購入をオススメします！
Amazon: リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
##1.理解しやすいコード
###コードは理解しやすくなければいけない
###コードは他の人が短時間で理解できるように書かなければいけない
#Ⅰ:表面上の改善
##2.名前に情報を詰め込む
###明確な単語を選ぶ
・Getではなく、FetchやDownloadなど
###tmpやretvalなどの汎用的な名前を避ける
・ただし生存期間が短く、一時的な保管が最も重要な変数ならば使える
###抽象的な名前よりも具体的な名前を使う
###接尾辞や接頭辞を使って情報を追加する
・例えば、単位を追加する
###名前の長さを決める
・スコープが大きい→長くてもOK、スコープが小さい→短くてもOK
・省略形：初めて見た人だけでも理解できるものに限定する
###名前のフォーマットで情報を伝える
・アンダースコアでつなぐのかキャメルなのか
##3.誤解されない名前
###名前が「他の意味と間違えられることはないだろうか？」と何度も自問自答する
###限界値を明確にするには、名前のまえに_minや_maxをつけよう
・first/last, begin/end なども範囲を示すのに有効
##4.美しさ
###見た目が美しいコードの方が使いやすいのは明らかである
###読み手が慣れているパターンと一貫性のあるレイアウトを使う
・重複させない
###似ているコードは似ているように見せる
・縦にまっすぐにする
###関連するコードをまとめてブロックにする
・ブロックごとに何の処理をしているのかコメントをつけるとGOOD
##5.コメントすべきことを知る
###コメントの目的は、書き手の意図を読み手に知らせること
###コメントするべきでは「ない」ことを知る
・コードからすぐにわかること
・コメントのためのコメントをしない
・ひどい名前はコメントをつけずに名前を変える
・「優れたコード > ひどいコード + 優れたコメント」
###コードを書いているときの自分の考えを記録する
・コードの欠陥にコメントをつける
###読み手の立場になって何が必要になるか考える
・質問されそうなことを想像する
・ハマりそうな罠を告知する
・「全体像」のコメント／要約コメント
##6.コメントは正確で簡潔に
###コメントは領域に対する情報の比率が高くなければいけない
###コメントを簡潔にしておく
###あいまいな代名詞を避ける
###歯切れの悪い文章を磨く
###関数の動作を正確に記述する
###入出力の説明には実例を使う
・// 実例：strip("ab","a")は"b"を返す
###コードの意図をかく
###「名前付き引数」コメント
###情報密度の高い言葉を使う
・【正規化する】 = 「余分な空白を除去して整形する。こうすれば、表記がわずかに違っていても同じものと判別できる」
#Ⅱ:ループとロジックの単純化
##7.制御フローを読みやすくする
###条件式の引数の並び順
・左辺:「調査対象」の式。変化する ／ 右辺:「比較対象」の式。あまり変化しない
###if/elseブロックの並び順
・肯定形を使う、単純な条件を先に、関心を引く条件を先に
###三項演算子を使うときの注意
・行数を短くするよりも、ほかの人が理解するのにかかる時間を短くする
###do/whileループを避ける → whileで書き直す
・繰り返し条件は下より上にある方がいい
###関数から早く返す
###ネストを浅くする
・早めに返してネストを削除する
##8.巨大な式を分割する
コードの主要な「概念」を読み手が認識しやすくなる
###説明変数
・変数名で、式を説明する
###要約変数
・大きなコードの塊を小さな名前に置き換えて、管理や把握を簡単にする
(その式の意味が要約された名前の変数に、式を入れる)
###ド・モルガンの法則を使う
###短絡評価の悪用
※短絡評価：&&や||使用時、左の値で評価が決まり右の値を評価しないこと
論理演算子のAND演算子(&&)と、OR演算子(||)の短絡評価(ショートサーキット)Add Star
→ 多用すると読みにくい。if文で分解できることがほとんど
##9.変数と読みやすさ
###変数を削除する
・役に立たない一時変数
・中間結果を送るためだけの変数を削除する
・制御フロー変数を削除する
###変数のスコープを縮める
###変数は一度だけ書き込む(可能な限り書き換えない)
#Ⅲ:コードの再構成
##10.無関係の下位問題を積極的に抽出する
※無関係の下位問題：そのコードの目標に直接的に関係しない、ある意味独立した(汎用性のある)機能が下位に存在していること
###無関係の下位問題は、切り分けて関数化しよう！
例：コードの目標「与えられた地点から最も近い場所を見つける」
コードの中で「球面三角法の第二余弦定理」の公式が必要になる
→ この複雑な公式をそのまま書いてしまうのではなく、関数に切り分け、コードの中では1行に済むようにしたら、確実にリーダブルなコードになる！
##11.一度に、1つだけ
###コードは1つずつタスクを行うようにしなければいけない
・コードが行っている「タスク」をすべて列挙 → タスクをできるだけ異なる関数に分割する
##12.コードに思いを込める
おばあちゃんがわかるように説明できなければ、本当に理解したとは言えない・
ーーーアルバート・アインシュタイン
- コードの動作を簡単な言葉で同僚にもわかるように説明する
- その説明のなかで使っているキーワードやフレーズに注目する
- その説明に合わせてコードをかく
「ラバーダッキング」と言われる技法
問題を声に出すだけ解決策が見つかってしまう。部屋に置かれたテディベアに必ず説明させている研究室もあったらしい。
###ロジックを明確に説明する
・結果、仮にif文の中が空っぽになったとしても、ロジック通りの方がわかりやすい
###ライブラリを知る
・jQueryは何を提供してくれている？
###この手法を大きな問題に適用する
・分解して考える、解決策を言葉で説明する
##13.短いコードを書く
最も読みやすいコードは、何も書かれていないコードだ
###その機能の実装について悩まないで - きっと必要ないから
・欠かせない機能を過剰に見積もらない
・すべてのプログラムが、高速で、100%正しい必要はない
###コードを小さく保つ
・汎用的な「ユーティリティ」コードを作って、重複コードを削除する
・未使用のコードや無用の機能を削除する
・プロジェクトをサブプロジェクトに分割する
・コードの「重量」を意識する。軽量で機敏にしておく。
###身近なライブラリに親しむ
・既存のライブラリで問題を解決できることを知らないことが多い
・たまには標準ライブラリのすべての関数・モジュール・型の名前を15分かけて読んでみよう
#Ⅳ:選抜テーマ
##14.テストと読みやすさ
###テストを読みやすくする
・大切でない詳細はユーザから隠し、大切な詳細は目立つようにする
###最小のテストを作る・独自の「ミニ言語」を追加する
・小さいほど、テストケースとして追加しやすくなる
###エラーメッセージを読みやすくする
###コードを完全にテストする最も単純な入力値の組み合わせを選択しなければいけない
###テストに優しい開発
・テストしやすいコードは、明確なインターフェースがある
##15.「分/時間カウンタ」を設計・実装する
・具体例なのでメモは省略
##解説
###身に付けるために
・実際にやる
・やってみると気づくこと
・ほかの人に読んでもらう
・当たり前にする
・続けることが大事
・コードで伝える