リーダブルコード
https://gyazo.com/914da1f753e8a9b711833b478e6cb46a
テキスト
まとめ
1章 理解しやすいコード
優れたコードとは、他人の理解する時間を最小にする(=理解しやすい)コード
効率が良くても「優れたコード」は書ける
「優れたコード」はたいていテストがし易い
2章 名前に情報を詰め込む
明確な単語を選ぶ
例:「なんでもかんでもGet」ではなく、FetchやDownloadなどが使えないか検討
tmpやretvalなどの汎用的な名前を避ける
意味が広いとどんな意味なのかわからないkadoyau.icon
明確な理由があれば利用可
具体的な名前を使って物事を詳細に説明する
ServerCanStart()よりCanListenOnPort()の方が明確
ミリ秒を表す変数名には後ろに_msをつける
これからエスケープが必要な変数名には前にraw_をつける スコープが数画面に及ぶ変数に1~2文字の短い暗号めいた名前をつけてはいけない
短い名前はスコープが数行の変数につける
つまり、短い変数は暗黙的に短いスコープを期待するkadoyau.icon
大文字やアンダースコアなどに意味を含める
例:クラスのメンバ変数にアンダースコアをつけて,ローカル変数と区別する
3章 誤解されない名前
最善の名前は誤解されない名前
コードを読んだ人が意図を正しく理解できる名前
曖昧な英単語が多い
filter, length, limit
上下の限界値を決めるときはmix, minを頭につける
包含的範囲ならfirst, lastを使う
包含/排他的範囲ならbegin, endを使う
ブール値は分かるようにis, hasなどを使う
否定形は避ける
× disable_ssl
二重否定になったときにわかりづらい!disable_sslkadoyau.icon
単語に対するユーザの期待に気をつける
get()やsize()は軽量なメソッドが期待されている
getでネットワークアクセスを伴う処理があるとこの期待が反される
4章 美しさ
一貫性と意味のあるやり方でコードを整えよ
複数のコードブロックで同じようなことをしていたら,シルエットも同じようなものにする
コードの「列」を整列すると概要が把握しやすくなる
順番に気をつける.ある場所でA,B,Cと並んでいたら,他の場所でもA,B,Cに統一する
空行を使って大きなブロックを論理的な段落にわける
段落ごとに要約コメントを入れる
フォーマッタをつかって揃えるのがいいkadoyau.icon 5章 コメントすべきことを知る
コメントの目的は,コードの意図を読み手に理解してもらうことである コメントするべきでは無いこと
コードからすぐ分かること
ひどいコード(例えば,ひどい名前の関数)を補うコメント
記録すべき自分の考え
なぜコードが他のやり方では無くこうなっているのか
コードの欠陥をTODO:やXXX:などの記法をつかって示す
定数の値にまつわる「背景」
読み手の立場になって考える
コードを読んだ人が「え?」と思うところを予想してコメントをつける
平均的な読み手が驚くような動作は文書化しておく
ファイルやクラスには「全体像」のコメントを書く
読み手が細部にとらわれないよう,コードブロックにコメントをつけて概要をまとめる
6章 コメントは正確で簡潔に
小さな領域にできるだけ多くの情報を詰め込む
複数の物を指す可能性がある「これ」「それ」などの代名詞を避ける
関数の動作はできるだけ正確に説明する
コメントに含める入出力の事例を慎重に選ぶ
コードの意図は,詳細レベルでは無く,高レベルで記述する
○ 値段の高い順に表示する
よく分からない引数にはインラインコメントをつかう
例:Function(/* arg = */ xxx)
多くの意味が詰め込まれた言葉や表現を使ってコメントを簡潔に保つ
7章 制御フローを読みやすくする
比較を書くときには,変化する値を左に,より安定した値を右に配置する
received < expected
if/else文のブロックを適切に並び替える
肯定形,単純,目立つものを先に処理する
三項演算子,do/Whileループ,gotoなどのプログラミング構成要素の代わりに代替手段を使う
読みづらくなることが多い
三項演算子がネストする地獄を想像して欲しいkadoyau.icon
深いネストを避ける
ネストが増えるたびに記憶スタックにプッシュすることが増え,コードを追う労力がかかる
直線的なコードを選択する
早めにreturnする
ネストを削除したりコードをクリーンにできる
ガード節が便利
関数の上部で単純な条件を先に処理する
8章 巨大な式を分割する
巨大な式を一度に理解するのは難しい
説明変数を導入するメリット
巨大な式を分割できる
簡潔な名前で式を説明することで,コードを文書化できる
コードの主要な「概念」を読み手が認識しやすくなる
if(!(a && b)を(!a || !b)にしたり
複雑な論理条件を分割する
if(a < b)...のような小さな文にする
if文の中身が1行におさまるのが理想
いつでもできるとはかぎらないが,問題を「否定」したり,反対のことを考えてみよう
複雑なコードブロック(ロジック)も分割しよう
9章 変数と読みやすさ
プログラムの変数はすぐに増えて読みづらくなる.変数を減らそう.
邪魔な変数を削除する
中間結果の変数は,結果をすぐに使えば削除できる
変数のスコープを小さくする
変数を数行のコードからしか見えない位置に移動する
一度だけ書き込む変数を使う
変数に一度だけ値を設定するればコードが理解しやすくなる
const(C++)やfinal(Java)で不変にする手もある
10章 無関係の下位問題を抽出する
プロジェクト固有のコードから汎用コードを分離する
プロジェクトから独立しているものを分離
ファイルの読み書きなど
特化した機能を分離
パースなど
独立していなくても下位問題を取り除くと読みやすくなる
一般的な問題を解決するライブラリやヘルパー関数を作る
結果としてプログラム固有の小さな核が残り,それに集中できる
コードの再利用もできる
11章 一度に1つのことを
一度に1つのタスクを行う
読みにくいコードがあれば,そこで行われているタスクをすべて列挙する
別の関数やクラスに分割できるタスクを発見する
それ以外は関数の論理的な段落になる
どう分割するかより,分割することが大切
ポイントは,プログラムが行っていることを正確に説明すること
12章 コードに思いを込める
プログラムのことを簡単な言葉で説明する
説明で使っているフレーズをよく見れば,分割する下位問題がどこにあるかがわかる
設計や問題をうまく言葉で説明できないのであれば,何かを見落としているか,詳細が明確になっていない
13章 短いコードを書く
できるだけコードを書かない
コードが増えると指数関数的に開発がめんどくさくなる
不必要な機能をプロダクトから削除する.過剰な機能は持たせない
最も簡単に問題を解決できるような要求を考える
定期的に全てのAPIを読んで,標準ライブラリに慣れ親しんでおく
14章 テストと読みやすさ
テストが読みやすければ,書きやすくなり,追加しやすい
本物のコードをテストしやすく設計すれば,コードの設計が全体的に改善できる
改善点
テストのトップレベルはできるだけ簡潔にする
入出力のテストはコード1行で記述できるといい
テストが失敗したらバグの発見や修正がしやすいようなエラーメッセージを表示する
テストに有効な最も単純な入力値を使う
テスト関数に説明的な名前をつけて,何をテストしているのか明らかにする
× Test1()
○ Test_<関数名>_<状況>
新しいテストの追加や修正を簡単にすること