リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
コードは理解しやすくなければいけない。
これがコードを書く上でいちばん大切な原則だ。
コードは他の人が最短時間で理解できるように書かなければならない。
これってどういう意味だと思う? そのまんまの意味だ。 例えば、同僚にコードを読んでもらって、彼が理解するまでにかかる時間を計測するとしよう。この「理解するまでにかかる時間」という数値を最短にするってことだ。「他の人」というのは、自分のコードに見覚えのない6ヶ月後の「君自身」かもしれない。
コードは短くしたほうがいい。だけど、「理解するまでにかかる時間」を短くするほうが大切だ。
名前に情報を詰め込む
size
やget
みたいに一見すると問題がなさそうな名前であっても、情報が含まれていないことがある。
情報を詰め込んだ名前のつけ方のテーマ
getPage(url);
この "get"
という単語はあまり明確ではない。もし、インターネットから "get"
するのであれば、
fetchPage(url);
// もしくは
downloadPage(url);
のほうが明確である。
tmp
や retval
などの汎用的な名前を避けるエンティティの値や目的を表した名前を選ぼう。
いい名前というのは、変数の目的や値を表すものだ。
ただ情報の一時的な保管や、生存期間が少ない行数の変数名には、tmp
という名前で全く問題ない。
ServerCanStart()
というメソッドよりも
CanListenOnPort()
のほうが具体的でメソッドの動作をそのまま表している。
時間やバイト数のように計測できるものであれば、変数名に単語を入れるといいだろう。
delay => delay_secs size => size_mb limit => max_kbps angle => degrees_cw
長期休暇よりも短期でどこかへ行くときのほうが荷物は少ないはずだ。それと同じで識別子の「スコープ」(その名前が「見える」コードの行数)が小さければ、多くの情報を詰め込む必要はない。すべての情報(変数の型・初期値・破棄方法など)が見えるので、変数の名前は短くていい。
プロジェクト固有の省略形はダメだ。
新しいチームメイトはその名前の意味を理解できるだろうか? 理解できるなら問題ない。
evaluation => eval
document => doc
string => str
をプログラマは普段から使うから、新しいチームメイトも formatStr()
の意味は理解できる。
convertToString() => toString() doServeLoop() => serveLoop()
に変えても明確さは同じ。
結構カジュアルというか、口語的に内容が展開されているのですがそれが読みやすいです。
また次回覚えておきたいことをメモしていきたいと思います。