🧨 賢そうに見えるが読めないコード（Readability counts / Beautiful is better than ugly）
🧭 はじめに
このページでは、「短い・凝っている・トリッキー」なコードが必ずしも良いコードではないことを整理する。 Python の Zen が繰り返し強調する Readability counts と Beautiful is better than ugly は、好みの話ではない。保守性と生産性の話である。
🎯 ねらい
- “一行で書ける＝優秀” という誤解を正す
- 「読む速さ」を最適化するという設計視点を取り戻す
❓ 問題の定義
- 表現を詰め込みすぎて、理解に時間がかかる
- 書いた本人しか説明できないコードになる
賢さの誇示は、未来の自分への負債になりやすい。
🧪 よくある症状
- 内包表記が三重以上で、条件と変換が同居
- ラムダがネストし、処理の段階が読めない
- 演算子の優先順位に強く依存した式
- コメントなしの一行芸
❌ 悪い例
一行に全てを詰め込む
- 「短いが、口頭で説明できない」
- デバッグ時に途中状態を確認できない
読めないコードは、直せないコードになる。
✅ 良い例
ステップを分解する
- 中間結果を変数に束縛する
- 各ステップに「意味のある名前」を付ける
小さな関数に切り出す
- 処理ではなく意図を関数名にする
- 呼び出し側が「物語」として読めるようにする
名前の付いた変数・関数は、最小のドキュメント。
🧠 設計の要点
- 速さを最適化すべき対象は CPU ではなく人間
- 可読性は性能の一部（保守・レビュー・修正速度）
- 「美しさ」は行数ではなく理解の直感性
Python は書く言語ではなく読む言語として設計されている。
🧰 チェックリスト
- 3秒で処理の意図を説明できるか
- 中間変数名が「何をしたか」を語っているか
- 後から条件を1つ足すのが容易か
- “賢そうに見せるため”に短縮していないか
🏁 まとめ
- 短いコード ≠ 良いコード
- 良いコードとは、他人がすぐ理解できるコード
- 読みやすさは、美徳ではなく設計要件
Python が評価するのは技巧ではない。 理解の速さである。