【リーダブルコード】誤解されない名前をつける
※ 下記のリンクにある本の韓国語版を読んで簡単に整理しました。
誤解されない名前をつける
filter の曖昧さに注意
「filter」という名前は、対象を選び出すのか、除外するのかが明確ではない。
- 対象を選ぶ →
select() - 対象を除く →
exclude()
というように、目的に合った動詞を使うだけで、コードの意図が格段に伝わりやすくなる。
// 曖昧な例
List<User> filter(List<User> users);
// より明確な例（選ぶ場合）
List<User> selectActiveUsers(List<User> users);
// より明確な例（除外する場合）
List<User> excludeInactiveUsers(List<User> users);
境界に関する変数名の使い分け
✅ min, max：境界値を含む限界を表す
int minAge = 18;
int maxAge = 65;
✅ first, last：境界を含む範囲を表す
int firstPage = 1;
int lastPage = 10;
✅ begin, end：含む／含まないを明示する汎用的な範囲
int beginIndex = 0; // 含む
int endIndex = 10; // 含まない
所感
これまでは min/max や start/end をなんとなく使い分けていたけれど、
文脈に応じて (min, max), (first, last), (begin, end) を明確に使い分けるだけで、理解しやすくなり、バグの可能性も減らせることを実感した。
同時に、「今までそこに違和感を持ってこなかった自分」に少し悔しさも覚えた。
Boolean変数に名前を付けるときは肯定形で
// ✖️ わかりにくい
boolean disableSsl = false;
// ✔️ わかりやすい
boolean useSsl = true;
否定形よりも肯定形の方が、より直感的に意味が伝わりやすい。
コードを読んでいる人が一瞬でも混乱する可能性を減らすには、こうした細かい配慮が大切。
ユーザーの期待に応える名前を使う
多くの人は、get で始まるメソッド名を「単に値を返すだけの軽い処理」と認識している。
しかし実際には、処理が重い場合や計算を伴う場合もある。
// ✖️ 内部値を取得するように見えて、実は計算している
public double getMean() {
// 重い処理（すべての履歴データを巡回など）
...
}
こういったケースでは、computeMean のように処理内容が推測できる名前の方が適切。
// ✔️ 実際に計算が行われることがわかる
public double computeMean() {
...
}
所感
これまで何でも get* で名前をつけていたけれど、今回の例を見て「あれ、これ本当に 'get' でいいのかな？」と考えるようになった。
読み手の立場になってみると、処理の重さや性質が名前からわかることの重要性を改めて感じた。
単なる文法的な正しさよりも、「意図が伝わるかどうか」が大事なんだと気づかされた。
第3章の感想
第3章では、ついなんとなく使っていた境界を示す変数名や get* メソッド名が、
実は誤解を生む原因になっていることに気づくきっかけとなった。
こうした「ちょっとした違和感」に敏感になり、気づいたときに素早く名前を直す癖を身につけていきたい。
名前付けは奥が深く、だからこそしっかり向き合うべきだと思わされた章だった。
現在では、GitHub Copilot のようなツールを使えば、命名にも一定の支援を受けることができる。
悩みすぎず、ツールも活用しながら、最適な名前をつける努力を続けていきたい。
Discussion