会社の有志で Robert C. Martin『Clean Code』の朗読会をやってます。
途中のページからになってしまいますが、自分の理解した内容を整理するためにブログに書くことにしました。
意味のある対比を行う（P.47）
変数の中に含まれてしまうノイズワードの中には「variable」「Table」「String」といったものが存在します。
『良いコード／悪いコード』でいうところの「技術命名駆動」です。
想像するに、こうした命名の動機はコードの見た目から型を判断しやすくすることであり、 著者の言い分としては現代の優秀な IDE が型情報をきちんと教えてくれるんだからその必要は無い、ということなんだと思います。
発音可能な名前を使用する（P.48）
自然な単語として発音可能という実用の面から訴えているところに説得力を感じました。
検索可能な名前を用いる（P.49）
ミススペルをするな、さもなくば検索にひっかからないぞ、ということかと思いましたが、違いました。
ここで言っている検索可能とは、理想的には目的の変数のみ、あるいはそれを変数名の一部とする変数名や関数名やクラス名のみが検索結果にあがってくるということではないかと想像しました。
しかし、もっと初歩的なことについて言っていますね。
エンコーディングを避ける（P.50）
はじめ文字コードの話かと思いましたが、どうやら違うようです。
一読しただけでは理解できなかったのでググってみると、次のように説明している方がいました。
エンコーディングとは、型やスコープの情報を変数やメソッドの名前に含める手法のこと（_privateMember、i_value のようなの）。
うーん、やっぱりよくわかりません。
「新しい社員が入ってきたときに……」という書き方をしているので、「名前解読」が必要な形に落とし込まれている命名を指して「エンコーディング」と呼んでいるのだと解釈することにします。
ハンガリアン記法（P.51）
読んだだけではよく分からなかったのですが、次の表現で理解できました。
ハンガリアン記法について思うことなんやかんや【Agent Grow Advent Calendar 2017：13日目】 – 自主的20%るぅる
dwExStyle とか lpClassName のように、変数名の前にその変数の属性や型を示すプレフィックス1)をつける命名規則がハンガリアン記法です。
プレフィクスつき変数名ということですね。そして、これはエンコーディングの一種なのでやめよう、ということです。
メンバープレフィクス（P.51）
メンバー変数に m_ をつけるやつ。Unity の C# で見たことがあります。
ただ、本に載っている Setter のサンプルコードはメンバープレフィクスの方が見やすいと感じました。
しかし、メンバー変数と仮引数が同じ識別子をとりながら this の有無で区別されているところに美しさも感じます。
メンバープレフィクスをつけないならつけないで、そこに秩序の存在を意識できるような記述が必要だと思います。
インターフェイスと実装（P.52）
プレフィクスに I をつけないというのは、かなり過激な主張だと感じました。
現に私は Unreal Engine のライブラリでプレフィクスに I のついたコードに慣れ親しんでいるので。
これも、著者の IDE への強力な信頼が下敷きになっているのではないかと思います。
私は正直ファクトリってなんだっけ？となったので、とりあえず勉強せなばなりませんね。
メンタルマッピングを避ける（P.52）
読む人に負荷をかけないという話。
私はコードを commit する前に、これを丹念に確認するのでまあ大丈夫でしょう。
クラス名（P.53）
異論なし。
メソッド名（P.53）
「コンストラクタがオーバーロードされている場合は……」のところの効用としては、ファクトリメソッド名を通して引数に意味を持たせているところでしょうか。
コンストラクタがあるからといって new しただけでは、その実引数が何の役割であてがわれているのかが分かりませんからね。
気取らない（P.54）
HolyHandGrenade = DeleteItems は厨二病でしょ。爆笑しちゃった。
平坦な英語を使いましょうという話。
1つのコンセプトには1つの単語（P.54）
これは他人の書いたコードに機能を追加する時に心がけるべきことだと思いました。
例えば、あるコードに他人が DeviceManager というクラスを書いていて、私が ProtocolController というクラスを書きたくなったら、まずは DeviceManager に合わせておくべきということ。
コードレビューかそれ以前かに確認するとよいかもしれないが、これを放置すると類似した単語のマジカルバナナになってしまう未来が想像される。
それはよくない。
ごろ合わせをしない（P.55）
add の例は分かりやすい。
が、コード中で利用しているライブラリの add と自分のコードの add の意味がバッティングしたらどうするか？
そういう時は、可能であればライブラリに寄せてしまうのが安全かもしれない。
だめなら external lib's 'add' means 'insert' などとコメントしておくとよいかもしれない。
以上。
