リーダブルコード輪読会 第2章
===

# 20201013

# ディスカッションをより豊かにするためのグランドルール

- 参加者は毎回任意
- 途中参加・聞くだけでもOK！

- ページ数と同時に、節のタイトルやキーワードを記入してもらえると探す手間を省けて嬉しいです

- ファシリテーターや話している人は集中しがちなので、話していない人に議論内容をメモ:pencil:してもらえると嬉しいです

- 気になる質問や同感するものには :+1: を末尾につけてください。

- 社外秘情報は書かないこと!!!
- オープン設定で誰でも見れてしまうので

# タイムテーブル

| 時間 | 所要時間 | 内容 |備考 |
| -------- | -------- | -------- | -------- |
| 15:00 | 5-10分? | (書いてなければ)感想記入&書かれた感想・気づき・疑問をもっと掘り下げたいものを、 :+1: 付けていく | |
| 15:10? | 40-45分 | 本の節ごとにディスカッション | |
|15:55? | 5分 | 次回読む範囲決めてクローズ | |

## 下に感想などを書いていって下さい。どんな些細なことでもOKです。

---

# 序章、2.1 明確な単語を選ぶ

## 感想・気づき
- p10 size, get は汎用的なので命名のアンチパターンになりつつある
- 汎用的な名前を命名すると、処理内容に曖昧さが生まれ(≒抽象的)、結果として責務がブレてしまい、変更と共に複雑化する原因となる

- p11 「カラフル」な単語と言う言葉のニュアンスがとても好きだなと思った

- p12 「やりすぎ」な単語を選ばないように、プログラマが良く使う英単語辞典とかほしい（何の開発しているかで使う単語変わってしまいそうですが）
- と思っていたらプログラマの必須英単語とかいうのもあるんですね。（ただ、できれば日本語の意味から英語の類語を調べたかった・・・）
- https://progeigo.org/learning/essential-words-600-plus/
→ こんなサイトもありますよ。[ネーミングツール Codic](https://codic.jp/engine):+1::+1:
- 名前の付け方はコードレビューでもっとも議論になる点の1つ。2章の内容をコーディング規約にすればいいのかな？
- 2.1の悪い例はほんとよくやりがちだと思う。そして、「明確な」単語を選ぶのがまたむずかしい。。。
- PHPの[split](https://www.php.net/manual/ja/function.split.php)と[explode](https://www.php.net/manual/ja/function.explode.php)
- 名前付け直すとしたら`splitByString` とか`splitByRegExp` とかかなあ…

## 疑問
- p12 「やりすぎはいけない」、これをどうやって判断するのか？:+1:
- 引数の命名など工夫すれば差別化できると思ったりするので、何を持って判断するのだろうか
- :pencil: 中学・高校レベルの英単語でなければやりすぎかも(伝わらない可能性がある)
- 値を返すのでなく、状態を変える関数の場合どう名づけるか迷うことが多い。
- どんな名前つけること多いかあったら教えて欲しい
- :pencil: switchStateとかchanged、completeOO

---

# 2.2 tmpやretvalなどの汎用的な名前を避ける

## 感想・気づき
- これは安易な変数の使い回しなどにも通じる話
- これをやられると、読むときに何度も遡って変数の意味を確認する必要が出てきたりして非常に厄介
- (p14 ループイテレータはプログラミング入門書がそう言う書き方してるせいもあるでしょ！とか言いたくなるやつ)
- tmpはJavaを習ったときにもサンプルに何度も登場していたので、避けた方がベターだとあって驚いた
- エラーコードが戻り値の時に、戻り値の変数をretなどの名前で定義しがちだった。errorCodeとかの方が良かったか。
- スコープ内外で同じ変数名使われ、どっちがどっち？となることが多い

## 疑問
- p15 汎用的な名前をつけるときの基準あったりしますか？
- あえて汎用的な名前を使わない理由が出てこない場合のみにした方が良いのではと最近思ってる
- :pencil: スコープが短い場合、生存期間が短い、慣例のパターン

---

# 2.3 抽象的な名前よりも具体的な名前を使う

## 感想・気づき
- p17 EVIL自体に意味はないが、危険だと言うのは伝わるので、そんなに悪くないのではと思ってしまったw
- コードをガリガリ書いてる時は、名前どうするかに時間かけずに書き進めてしまい、後でそのままになってしまいがち。じっくり考えればもっといい名前がありそうと思いながらも、やれてない気がする。

## 疑問
- 一つ目の例がどんな意味を持っているのかピンときていない
- やって欲しくない操作を明確に書けてないか、という点がよくなさそう

---

# 2.4 名前に情報を追加する

## 感想・気づき
- p20 値の単位は、ライブラリ使うときに見落として、後で悲しいことになったりするので要注意なやつ
- p21 ハンガリアン記法は、今はどちらかと言うとアンチパターンになってきてるので注意:+1:
- どの情報が重要な変数なのか意識して名前をつけることが大切だとわかった
- `変数の意味を理解してもらわないと困るところに属性を追加`が重要

## 疑問
- なし

---

# 2.5 名前の長さを決める

## 感想・気づき
- p24 「不要な単語を投げ捨てる」、経験がものを言いそうな箇所で、意識していてもまだまだと感じるところ
- 何か良い方法ある人いませんかね？
- スコープの大小と変数名の大小の関連は考えたことがなかったけど納得
- メソッド名が長くなりがち。メソッドに役割が多いか、メソッド名だけで全てを伝えようとしている気がする。:+1:
- :pencil: やることが2つあるメソッドの名前(よく使うからまとめてしまいたい2つの処理)はどうしたら？ ex.) checkAndConnect
- :pencil: connect() にする。本当にやりたいことに絞る

- 1文字の変数はわかりにくい。p23のようにif句の中だけぐらいならいいが、そこそこのメソッド内で多用されると、「ｍってなんだっけ？」とかになる

## 疑問

- なし

# 2.6 名前のフォーマットで情報を伝える

## 感想・気づき
- (言語によって様々なのでコメントしづらいやつー)
- 言語ごとの一般的なコーディング規約を参考にするとか
- 例に挙げられているGoogleのC++規約とか

## 疑問
- なし