# ゆるふわ読書会　第二回

課題図書
---
- [リーダブルコード](https://www.amazon.co.jp/dp/4873115655)

@jupipi
---
- 3章
- filter()は配列から絞る時にプロジェクトでは使われているが、避けるべき？
- beginとendはあまり使っている印象がない
- ブールはisはよく使っているhasもcan,shouldはあまり
- max,minも使うがそれ以外はあまり使わない？

- 4章
- コードの「見た目をよく」すれば、表面上の改善だけではなく、コードの構造も改善できる
- ぶっちゃけまずは動くコードも書くことが先決なためまだその領域に達せていない
- Linterのお陰でコードの整形は担保してくれている。
- 処理事にかたまりにしたり、段落にするのは確かに現場でもやっている（自分ができているかは別）
- この章はコーディング規約が書いてあればそれに従い、なければプロジェクトのコードを読んでその通り書くしかなさそう

- 5章
- 関数の名前でわかりにくい処理をわかりやすい命名規則をつけることで、わかりやすく（とにかく短くすることしか考えていなかった）
- 現場だとコードの処理よりも変数の中身？をコメントで書いてあることが多い気がする
- 酷いコードに優れたコメントをつけるより、優れたコードの方が良い
- 今のプロジェクトだとそんなに頻繁にコメントを書いてある様子はない（単純にコードが見やすいから？）

- 6章
- コードもコメントも考え方的には同じだと読んでいて感じた
- 簡潔にかつ読みやすく、短すぎず長すぎず
- 正直、わかりやすいコメントを書く領域まで達することができていない

@gkzz
---
- 3章
- プログラミングの変数の命名力は、最低限の英語力があれば、ドキュメントで使われる単語で知ったほうが良いと思う
- 4章
- 改行する、しないはプロジェクトのローカルルールに従う、なければGoogleらが出しているコーディング規約に従う
- > 3.2 パッケージ文
- > パッケージ文は 改行してはならない。 文字数制限（4.4節 文字数制限は100文字 ）はパッケージ文には適用されない。
- > import文は 改行してはならない。 文字数制限（4.4節 文字数制限は100文字 ）はimport文には適用されない。
- cf. [Google Java Style Guide (非公式和訳)](https://kazurof.github.io/GoogleJavaStyle-ja/)
- 5章
- コードには How
テストコードには What
コミットログには Why
**`コードコメントには Why not`**
https://twitter.com/t_wada/status/904916106153828352?s=20
- コメントの目的は、書き手の意図を読み手に知らせること
- **`コメントするべきでは「ない」ことを知る。`**
- コー ドを書いているときの自分の考えを記録する。
- 読み手の立場になって何が必要になるかを考える。
- コードからすぐにわかることをコメントに書かない。
- ひどい名前はコメントをつけずに名前を変える
- TODO/FIXMEなどが付いたコメントが消えることケースに出会ったことがない
- 「コードからすぐ分かることはコメントしない」と「あまり知られていない書き方の解説をするためにコメントする」塩梅とは？
- ファイルの機能に関する要約コメントまでいるか
- ココでいうコメントとは、たとえばpythonのmethodの下にコメントアウトされたメソッドのディスクリプションのことなら必要と思う。ディスクリプションは__docs__で取得可能。
- 6章
- コメントの改善方法はなるほどと感じた。同時にバーバラミントのロジックピラミッドのイラストを思い出した。本来は自分の閃いたコメントに対して自問自答して上方の密度を高めていくべきだろうけどできていな い。できていないのは自問自答が面倒だと思っているから。

@あれふ
---
- 3章
- 処理の目的に対して適切な名前を付けるように意識する
- この本では「これが正解！」ということではなく、ちゃんと考えようね、という問いかけ
- 名前は何度も叩いて叩いて検討するに値する
- コードレビューで議論にしよう
- 同じ処理内容でも適切な名前をつけたメソッドでラップする
- 4章
- IDEのフォーマッターを必ず使用する
- コードレビュー時にフォーマットがかかっていないコードを上げてはいけない
- レビューアの脳リソースを奪う害悪
- 保存すると自動でフォーマットされる設定にするとベスト
- 定義や引数をスペースで調整して表形式にすると可読性が上がる
- Linuxコマンドのヘルプドキュメントは綺麗に整列されていて苦労が垣間見える
- 5章
- 意味のあるコメント
- コメントに**気持ちを込めるッ！**
- 経験則的に「優れたコードであればコメントはいらない」を語弊して認識している人がいる
- コメント不要/必要の2択ではない
- どんなに優れたコードでも英語圏の人と日本語圏の人では前提が異なる
- メソッド名だけで表現するには限界があるのでコメントは補助的に活用した方が良い
- 実装する前に「何をするのか」を先にコメントで羅列するといい
- 実装してコメントが不要になれば削除
- 読み手の助けになるようであればより具体的にして残す
- 6章
- メソッドのドキュメントに使用方法や実例を記述する
- JSDoc,JavaDocという便利な機能がある
- IDEではドキュメント参照できて**利用する側**にとって役に立つ

@akaiwa
---