Robert C. Martin先生のCleanCode第2章を読んだメモ。

意味のある名前(第2章)の概要

  • 意図が明確の名前にする。
    • 名前の解説が必要なら、その名前は明確ではない。
    • 名前が意図を明確にしていなければ、コードが変更しづらくなる。
  • 偽情報を避ける
    • Unixプラットフォームに使われている名称や、エンジニアが誤解しやすい名前を避ける
      • hp,aix,scoなど
      • ListじゃないのにListなど
    • 似た概念に似たつづり
      • HyperTextMarkupLanguageForEffectVanilaとHyperTextMarkupLanguageForEffectJqueryなど。
      • 違いに気づくのに時間がかかる。
      • 自動コード補完の時にも使いにくくなる。
  • 意味のある対比を行う
    • ノイズワードを利用しない
      • a1などの意味のわからない名前を利用しない。
      • InfoやDataなどの意味のある単語を利用しない。
      • variable変数など
    • 読み手に違いが明確に伝わる名前を利用する。
      • getAccount(), getAccounts(), getAccountInfo() などの名称だとどれを使えば良いかわかりづらい
  • 発音可能な名前をつける
    • 造語を利用しない
      • 覚えづらいから
    • その名前のコードについて話しているときマヌケっぽい。
  • 検索可能な名前をつける
    • 1文字の名前は間違いなく検索できない
    • マジックナンバーも検索できない。
  • エンコーディングを避ける
    • ミスタイプの原因になる。
    • 発音可能なことはまずない
    • 精神的苦痛以外の何物でもない
  • ハンガリアン記法
    • 現代の記法じゃない。
      • コンパイラが型をチェックしてくれない時代の産物
  • メンバープレフィックス
    • m_でメンバ変数を表すなど
      • IDEで色分けしたら解決する問題なので、古い。
  • インターフェースと実装
    • インターフェースにIRepositoryのようなプレフィックスをつけない。
      • 散漫・情報過多
    • どうしてもつける場合は具象クラスにRepositoryImplなどの方が良い。
  • メンタルマッピングを避ける
    • 1文字の変数名をやめろ
      • forのiとかjは慣習なのとスコープが狭いから見逃しているだけ(l(小文字のエル)だけは許さない)
  • クラス名
    • 名詞で書く。動詞では書かない。
    • Manager, Info, Data, Processerとかは避ける。
  • メソッド名
    • 動詞で書く。
    • Javaビーンズによれば、先頭に get, set, is のいずれかを置くと良い。
    • コンストラクタのオーバーロードは、staticでFactoryを書いて、名前に引数を定義する。(DataModel.formFirebaseSnapshotなど)
      • もちろんConstructorで定義できるのが一番良い。
  • 気取らない
    • ウィットに富んだ名前をつけない(abort -> eatMyShorts{私のパンツを食べろ}のような)
    • 面白さより明確さの方が価値があるから
  • 1つのコンセプトには1つの概念
    • get, fetchなどが同じ意味で使われないようにする。(以下のように使い分ける)
      • get -> 通信をせず、オブジェクトをストレージなどの内部リソースから取得
      • fetch -> 通信して取ってくるリソースを取ってくる
    • 語彙集があると重宝する。
  • 語呂合わせをしない
    • addが2つのものを連結する目的で多くの箇所へ実装されていた場合に、コレクションに要素を追加するメソッドに対して add と名付けない。appendやinsertなどの命名にする。
  • 解決領域の用語の使用
    • 何でもかんでも、解決領域から命名すれば良いってもんじゃない。
      • JobQueueなどのプログラマがわかる命名をつけるのは決して誤りではない。
      • 無理やり業務用語から持ってくる必要はない。
      • いちいち業務用語の意味をお客さんやプロダクトオーナーに聞き取らなくてはならないから。
  • 問題領域の用語を使用
    • 処理内容がプログラマチックでない場合は、問題領域から名前を取ってくると良い。
    • 解決領域と問題領域を切り分けるのは優れたプログラマや、設計者の仕事の一つ
  • 意味のある文脈を加える
    • メソッドを細かく分割し、その中に変数を定義するなどでどの文脈なのかを明確にした方が良い。
  • 根拠のない文脈を避ける
    • メールマガジンシステムでネームスペースMailingList内にメールアドレスを表すクラスを作る時に、AccountAddressなどは避けた方が良い。
      • MailingListネームスペースの中にあるからAddressでメールアドレスの意味は伝わるはず。
      • アカウントのアドレス以外何が存在するのか。
  • 最後に
    • Robert C. Martinは名前の変更は感謝しつつ受け入れている。
    • 名前の変更は、結果はすぐに現れて長い期間効果を発揮する。

感じたこと

わかりみが深い。
ただ、クラス名の必ず動詞つける部分は概ね同意だが、以下のようにCleanArchitectureでUseCaseを動詞にするのはままありそうなので、 根拠のない文脈を避ける と、 Class名 はコンフリクトすることはありそう。

参考: https://github.com/android10/Android-CleanArchitecture/issues/258