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

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

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

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

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

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

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

# タイムテーブル

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

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

---

# 序章、7.1 条件式の引数の並び順

## 感想・気づき
- 条件分岐は思考を複雑にする要素なので可能な限り減らす、そのためのオブジェクト指向と言ってもいいレベル
- :pencil: レビューで、条件文がたくさんある場合に設計見直しで改善できそうということはある。時間的にやらない場合がほとんど > 黙認になる > 気付きにもなるので、言うだけは言ったほうが良い > その後に後でやるリファクタリングのチケットにする、途中までやるなど
- :pencil: オブジェクト指向言語なのに手続き型的な書き方とか
- :pencil: 保守的なテーマだと、いいコードにしようと設計を変更したりすると影響範囲を極小にせよと言われる場合がある
- ヨーダ記法という言葉自体忘れてた
- C++の皮をかぶったCを書いているときは、if(定数 == 変数)って書いてって指摘された記憶がある
- （ちょっとズレるが）Cプロジェクトでコーディング規約にはNullPointerExceptionを防ぐ目的で以下の書き方が推奨されている。
- :pencil: 大文字の方は定数で null にならないので、大文字の方でメソッド呼び出ししている

// 誤
if (fileName.equals(FILE_NAME)) {
if ((fileName != null) && fileName.equals(FILE_NAME)) {

// 正
if (FILE_NAME.equals(fileName)) {

## 疑問
-

---

# 7.2 if/elseブロックの並び順

## 感想・気づき
- 基本的に否定形の形を使わない、どうしても否定形になる場合、変数化して直接条件に含めないようにしたいという感想
- 下の方にある`not file`も名付けしてるので同じニュアンスで捉えてそう
- すごい分かる話なんだが、条件が複数ある場合にこれで順番を変えようとして、漏れが発生する場合があったので注意
- :pencil: テストコードでの網羅で回避できそう
- :pencil: テストないのにリファクタリングしてはいけない
- :pencil: テスト環境構築のハードルが高い場合は、最悪実行コード内に書いてしまう手もある(バッドノウハウ)
- :pencil: DLL をテスト用のものに差し替えるという事例もある

## 疑問
- 特に順序がない場合もある？
- :pencil: 保留

---

# 7.3 三項演算子

## 感想・気づき
- 感覚的に判断していたが、選択はいい例だと改めて感じた
- デバッガ使いづらいというのはすごく同意
- なんかテクニックあったりする？
- :pencil: 次の行で止める？
- :pencil: else に入った時だけブレークしたい時は？ > できなそう？ > 条件付きブレークポイントで実現できる

## 疑問
- 三項演算子使う例どんなものあります？
- 画面の要素生成で使っているのをみたことがある
- :pencil: 画面の状態によってボタンの表示非表示を変えるコード
- :pencil: 同じ変数に代入する場合
- :pencil: Bad Example

CGFloat PRTweenTimingFunctionExpoOut (CGFloat t, CGFloat b, CGFloat c, CGFloat d) {
    return (t==d) ? b+c : c * (-pow(2, -10 * t/d) + 1) + b;
}

---
# 12/15(火)はここから
---

# 7.4 do/whileループを避ける

## 感想・気づき
- do-whileは自分で書いたことないかも
- 1回やる処理とループの処理が全く同じことがあまりないので、メソッドで分離してしまう
- バイナリデータの解析で使ったことがあるような。先頭からXバイトとって、それが1以上繰り返すといったような
- p91のcontinue、確かに感覚と違って戸惑いそう

## 疑問
-

---

# 7.5 関数から早く返す

## 感想・気づき
- 早期リターンと名前が付くくらい当たり前になってる、言語によっては`guard`が用意されてる
- :memo:後処理が必要な場合は一考の余地あり

## 疑問
-

---

# 7.6 悪名高きgoto

## 感想・気づき
- 大学の研究室のコードで見たことはある
- 組み込み系のコードで、ハードの制御とソフトのロジックが入り乱れている地獄コードで放り投げた記憶...
- VBAで例外処理のため使ってた覚えある
- Javaでtry-catch使えるのを知った時に感動した
- R標準でgoto文は禁止されていたはず。（他にはネストの深さや複雑度の上限が決まっていたはず）
## 疑問
- 逆にgoto使わなきゃいけない場合ってありますか？ ->使った方が楽な場合がある
- :memo:後処理にも段階があって、途中で抜けたい場合の後処理など
- :memo:ネストが深くなるのを防げるので楽になる場合もある

---

# 7.7 ネストを浅くする

## 感想・気づき
- p.94 変更差分の話は、その通りだと思うが、コーディングしてるときにそこまで意識できるかは正直怪しい:+1:
- 自分が理解できないor他の人に説明できるかが検討ライン
- SwiftやObjective-Cだとクロージャが深くネストして可読性低い書き方になる場合がある

## 疑問
-

---

# 7.8 実行の流れを追えるかい？

## 感想・気づき
- 構成要素の表にあるやつはどれも駆け出しエンジニアがつまづくものばかりだと思った
- 例外はまだ理解しやすい&よく使われるので慣れる気もする

## 疑問
- スレッド制御の整理ってどうやってます？

---

# 7.9 まとめ

## 感想・気づき
- コードで当たり前にやっているものが多く、言語化された理由を読むといろいろ考えるきっかけになってよかった

## 疑問
-