Meaningful Names (by Tim Ottinger)

Introduction

• 名付けがいっぱい
• なので良い名付けをしたほうがいい

Use Intention-Revealing Names

• 良い名前を選ぶのには時間がかかるが、将来的にそれ以上の時間が浮く

• 名前が答えるべきこと

  • なぜそれが存在するか
  • それは何をするか
  • それはどう使われるか
• コメントが必要な名前は意図を表現できていない

• 避けるべきもの

  • 意味のない名前

    • theList: List<int[]>
  • マジックナンバー

Avoid Disinformation

• accountListとかは良くない

  • 本当にList？

  • 本当にListだとしても、名前を「エンコーディング」するのは良くない

    • システムハンガリアン
• accountGroup, bunchOfAccounts, accountsなどがよい

• スペリングには一貫性を

  • 補完のときうれしい

• l,Oはやめよう

  • 1とl, 0とOは紛らわしい

Make Meaningful Distinctions

• copy(a1,a2)

  • a1, a2はdisinformativeではないがnoninformative
  • source, destination がよい

• ノイズとなる単語を避ける

  • data, info

  • a, an, the

    • 「a/anは局所変数、theは引数」といった取り決めがあるならよい
    • 名前被りを避けるためだけに導入するのはNG

• nameStringとかもNG

  • stringじゃないわけないだろ

Use Pronounceable Names

• 人類の脳は話し言葉をうまく処理するように進化してきたので
• 発音できないと、コードに関する会話がまともにできない

Use Searchable Names

• 1文字変数やマジックナンバーは検索性が悪い

• 例外: ごく短いメソッドのループ変数とかは1文字変数でもいい

  • 名前の長さはスコープの広さに対応する

Avoid Encodings

• 読むとき「解読」が必要で、精神的な負荷になる
• 発音できないことが多い
• タイプミスしがち

Hungarian Notation

• 昔は必要に迫られたこともあった

• モダンな言語では不要

  • リッチな型システム
  • コンパイラの型チェック

• 単なる開発の妨げ

  • 名前や型を変えるのが面倒

    • 片方変え忘れたりする
  • 読むのがしんどい

Member Prefixes

• メンバにm_とかつけるやつ

• いらない

  • いらないくらい、クラスや関数を小さくすべき

Interfaces and Implementations

• 例えば、ShapeのAbstract Factoryを作るとき

• class ShapeFactory implements IShapeFactoryは良くない

  • 利用者はそれがインタフェースであることを意識すべきでない
• 名前をエンコードするにしてもclass ShapeFactoryImp implements ShapeFactoryのほうがよい

Avoid Mental Mapping

• 読み手は名前を脳内で変換すべきではない

  • 【補】「要するにあれのことか」
• 問題領域/解決領域いずれの語彙も使用していないとおこる

Class Names

• 名詞か名詞句にせよ

  • Customer, AddressParser

• 動詞はNG

  • Manager, Processor

• 無意味な名詞もNG

  • Info, Data

Method Names

• 動詞か動詞句
• アクセサ、ミューテタ、述語はget,set,isプレフィックス

• コンストラクタをオーバーロードするときは、引数名に基づいてstaticなファクトリメソッドを生やそう

  • コンストラクタをprivateにすることも検討せよ

Don’t Be Cute

• ネタが分からないと理解できない名前を使わない

  • DeleteItemsの意味でHolyHandGrenadeとかはNG

Pick One Word per Concept

• fetchとretrieveとgetとか混ぜない
• controllerとmanagerとdriverはどう違うんだ？

Don’t Pun

• ダブルミーニングを避ける

• 例

  • 値がなければ生成、あれば追加するaddが既にあったとする

  • コレクションへの要素追加のaddを作らない

    • insertやappendといった単語を使おう

Use Solution Domain Names

• 読み手はプログラマなので、プログラマにわかる解決領域の単語を使おう

  • CS分野の単語
  • アルゴリズム名
  • パターン名
  • 数学の単語
• 解決領域の語彙がすでにあるのに、わざわざ問題領域の語彙を使わない

Use Problem Domain Names

• 解決領域に適切な単語がなければ、問題領域からとる

  • コードを読む人はドメインエキスパートに確認をとれる

• 問題領域/解決領域の区別は良いプログラマ/設計者のつとめ

  • コードは、問題領域の概念よりも多くのことに関与することがある

    • 【補】裏でジョブキューが動く、とかかなあ
  • そういったものの名前は問題領域からは線引きして名付ける

Add Meaningful Context

• それ単体で意味が十分に伝わる名前はあまりない

• 例: state

  • それ単体で「住所の『州』」だとは伝わらない
• クラスで包むなどして、コンテキストを与えよう

Don’t Add Gratuitous Context

• 意図が明確に伝わる限り、名前は短いほうが良い

• アプリケーションのプレフィックスなどを無駄に付けない

  • アプリケーション横断的な再利用性も損なわれる

• 住所とMACアドレスとWebのアドレスを区別したくなったら？

  • PostalAddress, MAC, URIクラスを作る

    • 無駄にMACAddressとか長くしない

英語

• entrenched

  • (考え方などが)凝り固まった

• copious

  • 大量の、おびただしい

• contrivance

  • 考案、発明

• imperative

  • ぜひともしなければならない

• crutch

  • 松葉杖
  • (精神的な)支え

• colloquialism

  • 口語

• lexicon

  • 語彙

• gratuitous

  • 不要な