# ゆるふわ読書会　第一回

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

@jupipi
---
- 1章
- 優れたコード（各々が見やすいコード）
- 理解しやすいコードを書いた結果、優れた設計やテストのしやすさに繋がる
- 処理を早くするには短いコードが良いが本書によるとコードが長くなるが理解するまでにかかる時間を短縮するのが良しとされている
- コードを読む力量がまだまだの人がプロジェクトに入った時にそもそもわかりやすいコードを書くことができたり、どんなコードがわかりやすいのか判断できるのか？コードを書いた側が複雑なロジックを書いたのが問題なのか？
- わかりにくさはバグに繋がる？

- 2章
- 実務でも変数名のセンスがあるやらないやらの話はあって、基本的に一目見て何をするかわかることが求められている
- プロジェクトwikiを見たら変数名はコーディング規約でスネークケースを使うのかキャメルケースを使うのかなどが決められている
- 抽象的ではなく、具体的にわかりやすく命名することが必要。これは正直、慣れ？
- プログラミングでよく使われる[英単語](https://qiita.com/Ted-HM/items/7dde25dcffae4cdc7923)
- 変数によく使われる[省略形](https://qiita.com/Shons_a/items/bd6eed229253ee266b7d)
- 上記のリンク英単語で省略形をある程度、見てたたき込んだ方が話が早そう

@gkzz
---
- 1章
- チーム内にコーディング規約、コーディングルールは？
- ある場合、規約を作る前にメンバーは本書を読んだ？
- > **`「簡潔さ」と「安心さ」はどちらが大切？`**
- 「安心さ」と「簡潔さ」それぞれ「コードを読む者にとっての」と補完できるとすれば、「安心さ」を取りたい
- 「コードは書く時間より読まれる時間のほうが多い」と聞いたことがあるので。
- これが本書でいう、「コードは他の人が最短時間で理解できるように書かなければいけない」ということに繋がると考える

- 2章
- 名前は具体的に、意味があり、非汎用的であること
- for-loop/whileといった変数の一時利用（都度、値が変わる変数）の場合はtmp, current_orderなどと、意図して変数は汎用的なものだと伝えることがある
- 既存のプログラムで使われている名前と粒度、スコープがズレることのないようにすることは大前提？
- ディレクトリ名はある程度似たり寄ったりになる？
- e.g.: https://github.com/gothinkster/laravel-realworld-example-app

@あれふ
---
- 1章
- 「優れた」コードって何？
- 例に挙がっているfor文は定型化されているので短くても読みやすい
- ロジックとしてパターン化されている
- 独自のロジックこそわかりにくい
- プログラマという生き物は悦に浸りやすい
- 独自のロジックはある程度冗長に記述したりコメントを追加したほうがわかりやすい
- 読みやすさの基本定理
- 簡略化しすぎて未来の自分が読み返したときにわからない
- 無理にコードゴルフしない
- 特に否定の複合
- ドモルガンの法則を利用する

- 2章
- 汎用的な名前を避ける
- 雑にtmpやhoge,fooなどを利用しない
- かといって別の言葉にしたときにわかりにくくなってしまっては本末転倒
- 値の単位
- 関数を定義する際の仮引数名につけてあげるとドキュメントとしてもとても丁寧で良い
- 昔よくあったのは各単語の頭文字をつなげたもの
- 本当に害悪
- 名前が長いことはIDEを使うことで解決できる
- 長過ぎるのはよくないが、長くなることに恐れてはいけない
- フォーマット規約は効果的
- 例ではjQuery
- CSSのclassやIDをjavascriptで操作する名前に対してjs-プレフィックスを付けるなど
- うかつに消したバグの発生を未然に防ぐ

雑談メモ
---
@jupipi
１章
参入テストを全体に設ける。コーディング規約、コーディングルールなどがある。プログラマーが作るコードを一定レベルに作る

@gkzz
１章
コーディング規約があるかないかは重要。簡潔さと安心さのどちらを取るか。
クラスが別のファイルにもまたがるとわかりにくいので、コードを読んで誰しもがわかりやすくした方が良い。
バグは技術的負債になりがちになる。わかりにくい
読書会の[software engineering at google](https://www.amazon.co.jp/Software-Engineering-Google-Lessons-Programming/dp/1492082791)を以前読んで思った
プログラミンとエンジニアリングは違う
プログラミングはコードを書くだけ（使い捨ての場合）
エンジニアリングは今後を考えてコード書く（わかりやすく）

@あれふ
１章
優れたコード
基本パターンのロジックはわかりやすい、独自のロジックをしている場合はわかりにくい
コードスメルは独自ロジックがありわかりにくい。

簡潔とは冗長でも誰でもわかりやすいロジックで書いてあるコード

読みやすさの基本定義は未来の自分にわかりやすく（他の人に読んでもらうのはあまり考えられない）

２章
@gkzz
変数を広範囲で使うものはグローバルなものcurrentなんたら
システムに追加機能をつけたりする場合は、神クラスばかり作る場合になる
ディレクトリ名は似たりよったりになる。

@あれふ
２章
適切な名前をつける
ユーザーを取得する場合はみんなで推察できる単語など。
仮引数にID Eの補完
英単語を短縮するのはよくない
名前が長すぎるのは補完で使えば良い