【７月４週目】リーダブルコードを読んで【７〜９章 + リーダブルコードLT会レポート 】
第7章 制御フローを読みやすくする
条件式の順番
if文やfor文などの制御フローはできるだけ「自然」に理解できる文で書く必要がある。自然とは文章として読みやすいかどうかということで、例えば「お酒は２０歳を過ぎてから」という文は自然だが、「お酒は２０歳を過ぎていない人以外が飲める」というのは意味は同じだが、非常に理解しづらい。コードも同じように意味や振る舞いは同じだが、読みにくい場合がある。具体的にコードで見ていく。
コード１
def apple if price >= 100 puts " お金が足りません" end end
コード２
def apple if 100 <= price puts "お金が足りません" end end
上のコードを見比べてみると条件の書かれている順番が逆だということに気づく。コード１は「priceが100以上の時」と読めるのに対し、コード２は「100がprice以下の時」と書いてあり100が主語になっていて「100ってなんの100?」と混乱してしまう。今回はpriceを基準に比較する条件を書きたいわけだから最初に比較先が来てしまうと読みづらい制御フローとなってしまう。
if文を書く際はコード１のように比較元の後に比較先を書くと読みやすいので、コード２のように書かないようにしたい。
非定形より肯定系
まずは下のコードを見比べてみる。
コード１
if a == b { # 第１ケース } else { # 第２ケース }
コード2
if a !== b { # 第１ケース } else { # 第２ケース }
コードを見比べると僅かな違いだが１行目の「 ! 」の有無が違う。もし「aとbが同じなら」という条件に関心を置くプログラムだったとしたら、コード１が読みやすく、逆にコード２は否定から入っているので関心度が低いものが先に来てしまい、期待していない情報が先に来るので読みにくい。つまり関心を引く条件や目立つ条件を先に書かないと読みにくい制御フローとなってしまうので注意が必要だ。
第8章 巨大な式を分割する
説明変数
条件などの式は時々長くなるケースがある。多くの条件が絡んでくる場合などだが、これをそのまま書くと可読性が損なわれてしまう。そこで「説明変数」を使って式の記述と制御フローを分割して見やすくしていく。「説明変数」とは式を変数に代入し、その変数を制御フローに書くことで内容がスッキリし見やすくなる上に式も理科しやすくなるのがメリットである。以下は複数の条件があるif文で「説明変数」を使っている例である。長すぎる条件というわけではないが、使い方の参考として書いた。
total_price = price > 100 && price < 500 if total_price { # 第１ケース } else { # 第２ケース }
第9章 変数と読みやすさ
前の章では変数を使って読みやすいコードを書くという内容だったが、この章では逆に変数によって読みにくくなってしまうケースについて書いていく。本書では変数による３つの問題について書かれている。
1. 変数が多いと追跡するのが難しくなる
2. 変数のスコープが大きいとスコープを把握する時間が長くなる
3. 変数が頻繁に変更されると現在の値を把握するのが難しくなる
これらの問題を解決する方法を考えていく
不要な変数を削除する
不要な変数とは複雑な式を分割していなかったり、明確さが変数を書く前と変わっていなかったり、書いても記述量が変わらなかったりする場合に当てはまる。 以下のコードは記述量が減らない例である。
posts = Post.all
all_post = posts
これは素直に１行で書くのが見やすくて良い。
all_post = Post.all
リーダブルコードLT会
7月の中旬にオンラインで行われた「リーダブルコードのLT」のレポート
from.ラクス
saasをつくっている。1356名。東京大阪がメインで開発。拠点は名古屋にもある。
楽々精算や楽々明細は有名なサービス。
タイムテーブル
- ９人のLT
- ２０：５０〜 アンケートタイム
西原優人さん
- php
- ペンギン
リーダブルなPHP Doc
- とは関数の説明などのコメント
PHP メンテナンスした話
問題点３つ
- コメントが書かれているものと書かれていない間すが混在
- 書かれているけど統一されていない
- 内容が正しくないことがある
どうやって？
- PHP Docの修正
- 数千個の関数..
- 利用頻度の多い関数から
- 業務な合間にやった
- ルールの作成
- コーディングルールに追加した
- ルールの定着
- コードレビューの対象に追加
結果
- メンテは大変
- IDEの恩恵を受けることができた
結論
PHP Docをメンテしよう
きり丸さん
javaで書きます
いいコードとは？
- 悪くないコード
- Code Smellsに気をつけたらいい
- クラスにいっぱい書く
Primitive Obsessionとは
言語に用意されているデータ型しか使わないこと
ISBN
本を一意に特定するためのID
長さのチェックをする
１０桁は１３桁に変換する
最初の３桁でチェックする
UNO
山札などの表現はそれぞれ山札、手札、場札などに分けて定義する
まとめ
業務知識でコードを読むのではなくコードに行撃ち式を表現させると可読性が上がる
基本型以外を使って設計レベルアップ
よしでぶさん
最近「なんだこれと思ったコード」
Yahooの大阪
３年目
誰にとってのリーダブルコードか？
開発メンバー、自分、未来の自分、未来の開発メンバー
誰にとってもリーダブルにコード出ないといけない
三項演算子のネスト
Disabledは見やすい関数を書く
- isTodayなどどんなときにDisableが効くのかをわかるようにする
宣伝
ミックスリープ
名里梨沙
新人エンジニアが可読性を上げるためにやったこと
第三位
- コメントの重要性の可否
- 複雑なコードでない限りコメントをつける必要はない
第二位
名前がわかりにくい
接頭辞を使う
is〇〇
- 翻訳してから考える
- 自分が他人になると考える
- 関数として切り分ける
- 複数の処理を関数内で持たせるのは避ける
- ネストの深いコードは❌
第一位は聞き逃した
- コメントでコーディング
- コードを書く前にコメントで実行したい処理を日本語で書く
ニッキーさん
カンファレンスの主催
Pythonカンファレンスがあるらしい
値オブジェクトで読みやすく
目的に適したな名前
カラフル単語
「値オブジェクト」とは？
データ型を属性として１つか２つ
どんな処理をしているかがわかる
エディタの補完が効きやすい
静的方チェック
デメリット
小さいクラスを作るのでコード量が増える
joytomoさん
可音読性と非音読性
「こころ」が読みやすい理由
主語述語の順番が固定されているので読みやすい。
「たけくらべ」主語述語がバラバラだが、リズムが良くて効きやすい
Rubyは可音読性を重視する言語だと言える
括弧の省略ができる
v = Math.sin a
豊富なシンタックスシュガー
可音読性は現代の言語でも重要である
数学者は論理よりも美しさにこだわりを持っていた！
しかし、カントは「美しさは論理的には存在しない」
美しいコードは存在するが論証できない
フクロウラボ
人からわかる3分技術史
新たな視点
- 可音読性と可黙読性
- エンジニアのための人文読書会
- 文学からの視点でコードを見る
- 自然言語のようにわかるようにする
- 文字としてわかるコード
- 認知負荷の低いものが美しいと言われる
- ただ「これが美しいコードだ！」と言えるものはない
ZOMさん
株式会社Frontier Lotas 経営
全てのコードに意図を持たせよう
リーダブルじゃないコードとは
一貫していないコード
- インデントがずれている
- 改行が違う
- コメントがあるものとないものがある
理由
他の人に「どうしてだろう？」と思わせてしまう
一つ一つ意図がある
ベストプラクティス
- 公式のベストプラクティスを使う
- Lintなどを使う
- ちゃんとしたエディタをする
- 社内の規約に従う
- 先輩の真似をしてみる
会社の宣伝
スタートアップです！
三浦駿
ラクスル
チームでリーダブルコードを実現するには
私たちがチームでやったこと
勉強会
- 良い名前を使う
よかったこと
基礎力が上がった
共通認識が上がった
よくなかったこと
事前準備に数時間かかる
プルリクエストの公開レビュー
指摘事項の読み合わせ
よかったこと
どういう観点でレビューしているか
レビューを意識してコーディング
よくなかったこと
全員の時間が取られてしまう
イイダヨシキさん
クラウドワークスやってた
ログラスなう
リーダブルコードby DDD
リーダブルであるとは？
他の人が最短で理解すること
何をしているかがわかる
依存関係がわかる
ビジネス的な意味
理解できないと
実装の手戻り
バグ
品質の低下
DDD（ドメインモデリングから始まる設計）
ユーザーヒアリング
↓
ドメインモデル図
↓
仕様
テストケース
実装の目的の理解のしやすさ
実装の目的が失われてしまったシステムは変更難易度が桁違いになる
重要な要素
- 責務を一つに絞っていくことでリーダブルになること
- クラスを小さく
テスト
- テストが資産
- テストに関するコメント
- テストデータの可視化
日本語変数の活用
- 英語だとわかりにくすぎるものは日本語に
- 絶え間なくやる
- 責務を細かく分割する
見た目の美しさはLinterに任せる
まとめ
日本語変数使うという発想が新しかった
コメントコーディングは思考を整理するのに役立ちそう
公開コードレビューはいいと思った
DDDは名前は知ってたけどリーダブルコードに関係するとは知らなかった
三項演算子は見にくかったら普通のif文を使う
コードの美しさは定量化できないし証明もできないが、存在はする
言葉として読みやすいコードは美しい
可音読性と可黙読性という視点から見るコードの美しさ
