📖

リーダブルコードの「誤解されない名前」で学んだ命名の落とし穴

に公開
技術書
リーダブルコード
idea

はじめに

エンジニア歴2年半の私が「リーダブルコード」を読み進める読書記録シリーズです。第3章では、「誤解されない名前」の重要性について学びました。

第3章　誤解されない名前

基本原則：誤解されない名前 = 最善の名前

名前を見た人が、間違った解釈をしてしまう可能性を徹底的に排除する。

1. 上下の限界値を決める時は max_, min_ を使う

境界値を明確にする。

悪い例：

TOO_MANY_PASSWORD_LENGTH = 50  // 50文字まで？50文字未満？

良い例：

MAX_PASSWORD_LENGTH = 50  // 50文字以下が明確

2. 包含的範囲は first, last を使う

範囲に境界値が含まれることを明示。

紛らわしい例：

range(start=2, stop=4)  # [2, 3] or [2, 3, 4] ?

明確な例：

range(first=2, last=4)  # [2, 3, 4] が明確

3. 包含/排他的範囲は begin, end を使う

開始は含み、終了は含まないことを表現。

例：

PrintEventsInRange(begin, end)  # begin以上、end未満

4. ブール値は is_, has_ を使う

真偽値であることを明確にし、否定系は避ける。

悪い例：

disable_ssl = True  # 混乱しやすい

良い例：

is_ssl_enabled = True  # 意図が明確
has_permission = False

5. 単語に対するユーザーの期待に注意

プログラミング界の慣習に従う。

軽量なメソッドが期待される命名：

  • getXXX() → データベースアクセスなどの重い処理には不適切
  • sizeXXX() → 計算コストの高い処理には不適切

実務ですぐに活かせそうなポイント

  1. 境界値の命名 → max_, min_, first, last, begin, endを使い分け
  2. ブール値の命名 → is_, has_で始める、否定系を避ける
  3. メソッド名の期待値 → 処理の重さを暗示する名前選び
  4. 業界慣習の理解 → 一般的な命名パターンに従う

まとめ

第3章では「誤解を防ぐ」という観点を学びました。特に境界値やブール値の命名は、バグの原因になりやすい部分なので、この章で学んだルールは即座に実践していきたいと思います。

最後まで読んでいただきありがとうございました。

参考

Discussion