概要
リーダブルコードを読み、さまざまな可読性を高める手法があることを知りました。
これらをコード作成時に実践できているか確認するためのチェックリストを作成しました。
今後も可読性を高めるために満たすべき項目はアップデートしていこうと思います。
私がリーダブルコードを読んだ時の読書メモはこちらです。
実装・レビュー用チェックリスト
1. 命名(Naming)
- その名前で「振る舞い」が一意に伝わるか?
-
getなどの曖昧な言葉を避け、fetch,download,calculateなど明確な動詞を選んでいるか? -
抽象的な名前(
data,info)ではなく、具体的な名前をつけているか? -
tmpやitなどの汎用的な名前を安易に使っていないか? -
単位や属性を接頭辞・接尾辞で補足しているか?(例:
delay_ms,price_usd,p_node) -
境界値の命名は適切か?
-
最大・最小:
max/min -
包含範囲:
first/last -
包含/排他範囲:
begin/end
-
最大・最小:
- ユーザーが「軽量な処理」だと誤解するような名前に重い処理をさせていないか?
2. 表面上の改善(Aesthetics & Comments)
- 似ている処理は、見た目(インデントや改行位置)を揃えて一貫性を持たせているか?
- 関連するコードを「段落」としてまとめ、視覚的に構造化しているか?
- 「コードを読めばわかること」をコメントに書いていないか?
- コードの挙動ではなく、その値や処理に至った「背景・考え方・注意点」をコメントしているか?
- コメントの言葉は正確かつ簡潔か?(例:「行数」ではなく「改行文字数」など)
3. ループとロジックの単純化(Simplification)
- 条件式は「左側に変化する変数、右側に安定した値」の順になっているか?
- ガード節(早期リターン)を使って、if文のネストを浅くしているか?
- 巨大な式を、意味のある単位で「説明用変数」に分割しているか?
- ド・モルガンの法則を使い、直感的に理解しやすい条件式(否定が少ない形)にしているか?
- 変数のスコープ(有効範囲)を最小限に抑えているか?
- 変数は可能な限り「不変(Immutable/ReadOnly)」にしているか?
- 不要な制御変数(フラグ変数など)をループ内で使いすぎていないか?
4. コードの再構成(Refactoring)
- 「一度に一つのタスク」だけを行うように関数を分割しているか?
- 本筋とは直接関係ない「下位問題(ユーティリティ的な処理)」を別関数に抽出したか?
- 実装する前に、やりたいことを「簡単な言葉」で説明できるか?
- 既存のライブラリや標準機能で解決できることを、自作してコードを増やしていないか?
5. テスト(Testing)
- そのテストが「何を検証しているか」が一目でわかるか?
- テストケースに「境界値(エッジケース)」が含まれているか?
- テストがしやすい設計(副作用が少ない、疎結合)になっているか?