リーダブルコード輪読会 3章 === # ディスカッションをより豊かにするためのグランドルール - 参加者は毎回任意 - 途中参加・聞くだけでもOK！ - ページ数と同時に、節のタイトルやキーワードを記入してもらえると探す手間を省けて嬉しいです - ファシリテーターや話している人は集中しがちなので、話していない人に議論内容をメモ:pencil:してもらえると嬉しいです - 気になる質問や同感するものには :+1: を末尾につけてください。 - 社外秘情報は書かないこと!!! - オープン設定で誰でも見れてしまうので # タイムテーブル | 時間 | 所要時間 | 内容 |備考 | | -------- | -------- | -------- | -------- | | 15:00 | 5-10分? | (書いてなければ)感想記入&書かれた感想・気づき・疑問をもっと掘り下げたいものを、 :+1: 付けていく | | | 15:10? | 40-45分 | 本の節ごとにディスカッション | | |15:55? | 5分 | 次回読む範囲決めてクローズ | | ## 下に感想などを書いていって下さい。どんな些細なことでもOKです。 --- # 序章、3.1 filter() ## 感想・気づき - 「filter」ですら誤解される可能性があるのか、と多少の驚き - 個人的にはコード全体の統一感が取れてるなら妥協しても良いという考え、妥協すると今度は違反に気づくのは難しいが... - 原著は2011年発行なので、filter/map/reduceなどの操作が一般的じゃなかったからでは - 「誤解されない名前」、２章で見てきた汎用的な名前を避ける、具体的な名前をつける理由を説明する章でとても大事:+1: ## 疑問 - なし --- # 3.2 Clip(text, length) ## 感想・気づき - 「Clip」はたしかに誤解が発生しそう。lenghtはやりがち - p31 Truncateってそんな一般的な単語じゃない様に感じるが、、、 - :pencil:DB っぽい - 前者の例なら`remove(text, chars)`になる？ - `chars`はわかりづらい印象受ける:+1: - `max_chars` もわかりづらくない？ - `remove`の方に付け加えるのもあり ## 疑問 - なし --- # 3.3 限界値を含めるときは min と max を使う ## 感想・気づき - 昔はグローバル変数とかでよく見かけたが、最近はグローバル変数自体撲滅する傾向なのであまり見かけない気もする - 悪い例: `limit` - マジックナンバーが悪い理由: その数字の意味がわからない - :pencil:メソッド分割などで、定数を変数化しなくてもいいくらいスコープを小さくするという考えもある ## 疑問 - なし --- # 3.4 範囲を指定するときは first と last を使う ## 感想・気づき - 最近の言語で配列など標準ライブラリで実装されてるコードはだいたいこれなので違和感ないはず - 悪い例: `stop` - :pencil:3.4 と 3.5 も混ぜない方が良さげ first / last で統一が良さそう。 ## 疑問 - なし --- # 3.5 包含/排他的範囲には begin と end を使う ## 感想・気づき - 3.4と同じく違和感なさそう(lastとendの包含関係で混乱する人はいるかも) - endだと含まれているニュアンスの方が強く感じる - 実装するときはいつもendが含まれるのか、含まれないのかを調べて使っている。名前だけで判断するのは難しいのでは。 - first/lastとbegin/endの違いはどうしても混同しやすいからチーム内などで合意しても良さそう ## 疑問 - なし --- # 3.6 ブール値の名前 ## 感想・気づき - 肯定形にしたほうがいい、というのは同感:+1: - 否定系だと、解釈するのに１ステップ挟む感じがあり、理解に時間がかかる印象 - 否定系だと、特別が意味があるのかなと注目してしまう:+1: - 「is・has・can・should」が先頭についてると、Boolとすぐに認識できるのでとても大事 - 他に先頭につくパターンありますかね？Bool以外でもあれば - existsとか[(参考)](https://qiita.com/GinGinDako/items/6e8b696c4734b8e92d2b):+1::+1: - needs - :pencil:「状態」は `bool` ではない実装の方が良い - :pencil:`is・has・can・should`で表せないものは `bool` にしない方が良い ## 疑問 - なし --- # 3.7 ユーザの期待に合わせる ## 感想・気づき - サンプルの getMean()は、やってしまいがちな気がする - ここの3.7の内容が一番やってしまいがちで、大事な内容だと思った :+1: :+1: - コーディングしてるときは命名に違和感ないので、やってしまいがちですね - 命名するときに計算コストを意識した名付けはあまり考えたことなかったので、新たな気付き - 計算コストと名前に関係を持たせるというのは初めて聞いた :+1: - ここで言うユーザーはライブラリの利用者とか、将来の引継ぎ相手とかかな - :pencil:今書いてる自分以外全員をイメージした - コストのかかる処理だということは関数名で伝わりきらない気がする。関数名の工夫は必要だが、関数ヘッダに書くなりする方が大事に感じた。 - :pencil:できれば関数名で工夫を頑張って方が良い。ヘッダは呼び出し側には見えてこないので ## 疑問 - コストのかかる処理ですよ、をわかりやすく表す単語はどう言うものがあるだろう？ - :pencil:本では `compute` - :pencil:軽そう: get / set / is - :pencil:重そう: analyze / send / all / calculate / timeout が引数にある - ウィザードモードって若手わかるのかな笑 - :pencil:o さんもわからない。今でいう対話モード - :pencil:ウィザード = ハッカー --- # 3.8 複数の名前を検討する ## 感想・気づき - できれば一人ではなく何人かで検討したほうが良さそう:+1: - 単語のニュアンスの受け取り方が人によって変わりそう - GoFのデザインパターンのプロトタイプの[参考リンク](https://qiita.com/shoheiyokoyama/items/61826e158b3c4a259065) - 属性名の決め方との関連は？ - コーディングしてるときに、ここまで客観的に見直すの難しい... - :pencil: 複数の名前を検討することあった？ - :pencil: 命名規則も細かくコーディング規約で決められていた ## 疑問 - 書いている途中に検討する時間を取ることってある？ - :pencil: a さんはレビュー出す前に見直しする - :pencil: o さん 命名に限らず迷ったら小さい単位でも他の人にみてもらう - :pencil: i さん 気になりがあっても指摘しないことがある。レビューが期限ギリギリになってしまった場合など。(アンチパターン) --- # 3.9 まとめ ## 感想・気づき - ここまで読んでわかることは、英語のボキャブラリ大事...(ツラい):+1: - この処理に使われる一般的な単語を知らないとなかなか難しい - ぴったり当てはまる単語だとしても一般的でない単語（人によりますね）を使うのってどうなんでしょう、、、？ - SwiftはAPIの命名規則がわかりやすいなあ、と感じる - ただしUIKit/AppKitは別。[辛い](https://developer.apple.com/documentation/appkit/nsbitmapimagerep/1395538-init)のが多い。 ## 疑問 - なし # 参考リンク ## 命名 - [プログラミングの変数・メソッドの命名でよく使う英単語まとめ \- "BOKU"のITな日常](https://arakan-pgm-ai.hatenablog.com/entry/2019/04/15/000000) - [プログラミングでよく使う英単語のまとめ【随時更新】 \- Qiita](https://qiita.com/Ted-HM/items/7dde25dcffae4cdc7923):+1: - [プログラミングの変数名、関数名を命名する際に便利なサイト・記事 \- Qiita](https://qiita.com/developer-kikikaikai/items/421d4ab74e161d993074):+1: - [プログラミングで変数名や関数名のネーミングに迷ったときに便利なカンニングペーパーまとめ](https://nelog.jp/programming-words#%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%81%AA%E3%81%AE%E3%81%AB%E7%9F%A5%E3%82%89%E3%81%AA%E3%81%8B%E3%81%A3%E3%81%9F%E3%82%89%E6%81%A5%E3%81%9A%E3%81%8B%E3%81%97%E3%81%84%E8%8B%B1%E5%8D%98%E8%AA%9E%E9%9B%86) ## コードレビュー - [コードレビューの目的と考え方 \- osa\_k’s diary](https://osak.hatenablog.jp/entry/code-review-objectives-and-howto)