Clean Code ch2 Meaningful Names (by Tim Ottinger)
- Meaningful Names (by Tim Ottinger)
- Introduction
- Use Intention-Revealing Names
- Avoid Disinformation
- Make Meaningful Distinctions
- Use Pronounceable Names
- Use Searchable Names
- Avoid Encodings
- Avoid Mental Mapping
- Class Names
- Method Names
- Don't Be Cute
- Pick One Word per Concept
- Don't Pun
- Use Solution Domain Names
- Use Problem Domain Names
- Add Meaningful Context
- Don't Add Gratuitous Context
- 英語
Meaningful Names (by Tim Ottinger)
Introduction
- 名付けがいっぱい
- なので良い名付けをしたほうがいい
Use Intention-Revealing Names
- 良い名前を選ぶのには時間がかかるが、将来的にそれ以上の時間が浮く
- 名前が答えるべきこと
- なぜそれが存在するか
- それは何をするか
- それはどう使われるか
- コメントが必要な名前は意図を表現できていない
- 避けるべきもの
- 意味のない名前
theList: List<int[]>
- マジックナンバー
- 意味のない名前
Avoid Disinformation
accountListとかは良くないaccountGroup,bunchOfAccounts,accountsなどがよい- スペリングには一貫性を
- 補完のときうれしい
l,Oはやめよう1とl,0とOは紛らわしい
Make Meaningful Distinctions
copy(a1,a2)a1,a2はdisinformativeではないがnoninformativesource,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
Use Problem Domain Names
- 解決領域に適切な単語がなければ、問題領域からとる
- コードを読む人はドメインエキスパートに確認をとれる
- 問題領域/解決領域の区別は良いプログラマ/設計者のつとめ
- コードは、問題領域の概念よりも多くのことに関与することがある
- 【補】裏でジョブキューが動く、とかかなあ
- そういったものの名前は問題領域からは線引きして名付ける
- コードは、問題領域の概念よりも多くのことに関与することがある
Add Meaningful Context
- それ単体で意味が十分に伝わる名前はあまりない
- 例:
state- それ単体で「住所の『州』」だとは伝わらない
- クラスで包むなどして、コンテキストを与えよう
Don't Add Gratuitous Context
- 意図が明確に伝わる限り、名前は短いほうが良い
- アプリケーションのプレフィックスなどを無駄に付けない
- アプリケーション横断的な再利用性も損なわれる
- 住所とMACアドレスとWebのアドレスを区別したくなったら？
英語
- entrenched
- (考え方などが)凝り固まった
- copious
- 大量の、おびただしい
- contrivance
- 考案、発明
- imperative
- ぜひともしなければならない
- crutch
- 松葉杖
- (精神的な)支え
- colloquialism
- 口語
- lexicon
- 語彙
- gratuitous
- 不要な
