一緒に仕事させて頂いている方から、読むようにという指導が入ったので購入。メモを以下に列挙してみます。
以下、四つの部に分かれている、とのこと。
- 表面上の改善
- ループとロジックの単純化
- コードの再構成
- 選抜テーマ
最初に
- 簡潔と安心はどちらが大切か
- 理解しやすいコードを書く
表面上の改善
- 読みやすさ、はコードのすべての行に影響する
- 名前に情報を詰め込む
- 明確な単語を選ぶ
- 汎用的な名前を避ける
- 抽象的な名前より具体的な名前を
- 接頭辞や接尾辞を使って情報を追加
- 名前の長さを決める
- 名前のフォーマットで情報を伝える
命名力、低いなorz
- スコープが小さけれ ば短い名前でも良い
- 不要な単語
誤解されない名前
- 積極的に誤解を探す
- filter なのか、select なのか、exclude なのか
- 範囲の指定は first, last
- 包含/排他的範囲 (以上、未満) は begin, end
- bool な変数名は is, has, can, should な接頭辞 (ruby/scheme だと ? な接尾辞)
美しさ
- 整列、改行などについて
- 見た目を良くすれば、表面上の改善だけでなくコードの構造も改善される
- 並びに意味を付ける
- 宣言をブロックにまとめる
- コードを段落に
コメントすべきことを知る
- コードからすぐにわかることは書かない
- ひどい名前はコメント付けずに名前を変える
- 自分の考えを記録
- TODO:, FIXME:, HACK:, XXX: など
- 質問されそうなことを想像
- このコードを見てびっくりすることは何か、どういうふうに間違えるか、を自分に問いかける
- 要約コメントはブロックにつけても良い
- コードを理解するのに役立つ情報は何でも良いので書く
- とりあえず考えていることを書く
コメントを書く作業
- 頭の中にあるコメントをとにかく書く
- コメントを読んで改善が必要なものを見つける
- 改善
正確で簡潔に
- コメントは領域に対する情報の比率が高くなければならない
- 簡潔に
- あいまいな代名詞を避ける
- 正確にすることと簡潔にすることは両立することが多い
- 動作を正確に記述
- 入出力のコーナーケースに実例を使う
- コードの意図を書く
- 名前付き引数コメント
- 情報密度の高い言葉
ループとロジックの単純化
- 左側に調査対象となる変化する式、右側に比較対象となる (あまり) 変化しない式を書く
- 条件は否定よりも肯定を使う
- 単純な条件を先に
- 関心を引く条件や目立つ条件を先に
- if/else の順番
- 三項演算子は微妙
- do/while は避ける
- 関数から早く戻す (ガード)
- ネストは浅く (失敗ケースをできるだけ早く戻す)
- ループ内部のネストは continue でガード
- コードの行方を見失わない工夫
巨大な式を分割
- コードの式が大きくなると理解が難しくなる
- 飲み込みやすい大きさに
- 説明変数
- 要約変数
- 論理式を短かくする工夫 (ドモルガンの法則)
x = a || b || c
のような記述- 同じ式を要約変数を使って集約、という方法
変数と読みやすさ
- 役に立たない一時変数の削除
- 中間結果の削除
- 制御フロー変数の削除
- 変数のスコープを縮める
- スコープを縮めるためのクラス分割
- 変数に書き込むのは一度だけ、という方法 (これ、Elixir だな)
コードの再構成
コードを再構成する三つの方法について
- プログラムの主目的と関係のない「無関係の下位問題」の抽出
- コードを再構成して、一度に一つのことをやるように
- 最初にコードを言葉で説明、その説明を元にキレイな解決策を作る
無関係の下位問題の抽出
- 高レベルの目標とそれとは関係のない下位の問題解決との切り分け
- 小さな関数を作りすぎないこと
- プロジェクト固有のコードから汎用コードを分離
一度にひとつのことを
- コードはひとつづつタスクを行なうようにしなければいけない
- タスクのデフラグ
コードに思いをこめる
- プログラムのことを簡単な言葉で説明
- 説明することでコードがより自然になる
短いコードを書く
- 最も読みやすいコードは何も書かれていないコード
- コードをできるだけ小さく軽量に維持
- 汎用的なユーティリティを作って重複を削除
- 未使用のコードや無用の機能を削除
- プロジェクトをサブプロジェクトに分割
- コードの重量を意識する、軽量で機敏に
- たまには標準ライブラリのすべての関数・モジュール・型の名前を 15 分かけて読んでみよう
選抜テーマ
ここ、別途確認の方向で。