読者です 読者をやめる 読者になる 読者になる

かりっと揚げたらフライドポテト

㍋出る迄頑張るぞい

リーダブルコード読了後の備忘録

リーダブルコードを読み終わったので自分用におさらい
列挙次項に気をつけてコーディングしつつ、「あれ、どうやって実践するんだっけ?」ってなったら読み直す、ってのを習慣化したい
(注意)自分の解釈が混じってます

www.amazon.co.jp

名前に情報を詰め込む

  • 明確な単語を選ぶ
  • tmpやretvalなどの汎用的な名前を避ける
  • 具体的な名前を使って、物事を詳細に説明する
  • 変数名に単位、状態などを追加する
  • スコープの大きな変数に長い名前を
  • 大文字やアンダースコアに意味を込める

誤解されない名前

  • 曖昧な英語表現を使わない(ex: length, filter, limit)
  • 限界値にはmin, max
  • 包含的範囲にはfirst, last
  • 包含/排他的範囲にはbegin, end
  • ブール値にisなどを
  • 否定形を避ける
  • getやsizeは軽量アクセッサに限る

美しさ

  • 複数のコードブロックで同じことをするならシルエットも同じに
  • コードの列を整理
  • 順番は規則正しく
  • 空行を使って大きなブロックを論理的に「段落」に分ける

コメント内容

  • コードからすぐ抽出できることは書かない
  • 補助的なコメントは書かない(コードを補うコメント書くくらいならコード修正しろ!)
  • なぜ他のやり方でないのかを書く
  • コードの欠陥をTODO:やXXX:で表す
  • 定数の値にまつわる背景を書く
  • 読み手が疑問に思いそうなところを書いておく
  • 平均的な読み手が驚く動作は文書化する
  • ファイルやクラスには「全体像」のコメントを書く
  • コードブロックにコメントを付けて概要をまとめる

コメントは正確で簡潔に

  • 「それ」などの代名詞を避ける
  • 関数の動作はできるだけ正確に説明
  • コードの意図は詳細レベルでなく、高レベルで記述
  • よくわからない引数にインラインコメントを使う
  • 情報密度の高い言葉を使う

制御フローを読みやすく

  • 比較では変化する値を左に、より安定した値を右に配置
  • if/elseのブロックは、肯定形・単純・目立つものの順に処理する
  • 三項演算子、do/whileループ、gotoなどは避ける
  • 深いネストを避ける
  • 関数上部で単純な条件を先に処理するガード節を使う

巨大な式を分割する

  • 説明変数を導入する
  • if文の条件式が長くなるなら条件の否定を考えてみる

変数と読みやすさ

  • 中韓結果を格納する変数など、邪魔な変数を削除する
  • 変数のスコープをできるだけ小さく
  • 一度だけ書き込む変数を使う
  • プロジェクト固有のコードから汎用コードを分離する

一度に一つのことを行う

  • タスクを全て列挙して別の関数に分割できないか検討する
  • 言葉で説明して見ることが重要

短いコードを書く

  • 不必要な機能をプロダクトから削除する
  • 最も簡単に問題を解決できるような要求を考える
  • 定期的に全てのAPIを読み込んで標準ライブラリに慣れ親しんでおく
  • 質問と要求を分割する、あらゆる入力をうまく処理する必要はない

テスト

  • テストのトップレベルはできるだけ簡潔にする
  • テストが失敗したらバグの発見や修正がしやすそうなエラーメッセージを表示する
  • テストに有効な最も単純な値を入力につかう
  • テスト関数に説明的な名前をつけて、何をテストしているのかを明らかにする