リーダブルコード
「リーダブルコード」を読了した。いい本だった。こんなにいい本はひさしぶりかも。薄くて、訳がわかりやすく、さらっと読める。でも大切なことがぎゅーっと詰まってる。
リーダブルコードはリーダブルブックだった。
よいコードを書きましょうって書いてある本はたくさんあるし、何冊かは読んだ。なにが違うのか考えてみた。
- 原理、原則だけを書いているわけではない
- 理想論的ではなく、現実的な内容が書いてある
- 実践的なプラクティスが書いてある
たぶんこんな感じ。もうちょっと詳しく書く。
原理、原則だけを書いているわけではない
たとえば、コーディングルールを徹底するというのは、原理主義的なアプローチだと思う。コーディングルールを徹底するのは効果的で必要なことだけど、それだけではリーダブルコードにならない。
「3.7 ユーザの期待に合わせる」ではこんな例があった。
プログラマは get で始まるメソッドは、値を返すだけの軽量アクセサであるという規約になれている。そのため、コストの高い処理が get で始まると、コストの高さに気付かずに使ってしまうかもしれない。
サンプルのコードはこんな感じで
public double getMean(){
// すべてのサンプルをイテレートして、total/num_samples を返す。
}それなら computeMean() などの名前に変えるべきだ、とある。
なるほど。
理想論的ではなく、現実的な内容が書いてある
読みやすいコードを書くためには、コーディングルールではカバーできない、もっと別のアプローチが必要になる。その別のアプローチが本書には載っている。
「7.3 三項演算子」ではこんな例がある。
三項演算子がわかりやすい例としてこのコード。
time_str += (hour >= 12) ? "pm" : "am"
これはシンプル。で、わかりにくいコードはこれ。
return exponent >=0 ? mantissa * (1 << exponent) : mantissa / (1 << -exponent);
if文を使うと、コードが自然になる。
if(exponent >=0){
return mentissa * (1 << exponent);
}else{
return mantissa / (1 << -exponent);
}これならわかる。
実践的なプラクティスが書いてある
具体的で短いコードが提示されていて、改善するための考え方や、改善されたコードが記載されているのでわかりやすい。
この「具体的で短いコード」が、ほんとうに具体的で短いのでわかりやすい。こういうこと、これまでやっちゃったことあるなーと思うようなものが載っている。だから理解しやすい。
「2.2 tmpやretvalなどの汎用的な名前を避ける」では、こんな感じの2乗した値の合計値を返却するなら、retval ではなく sum_squares にしましょうって書いてある。
retval += v[i] * v[i]
例えば、sum_squares がこんな感じになってたら、名前からバグっぽいとわかる。
sum_squares += v[i]
確かに。
いくつかのプラクティスは、これまで無意識にやっているものだった。
このあたりのコードはごちゃごちゃしてるなー、なんかバグだしちゃいそうだなー、あとで読みにくそうだなーっていう、臭うコードはなんとなくわかる。それで、変数名を変えたり、メソッドを抽出したり、処理を分割したりする。
そのひとつひとつが、名前の付いたプラクティスとして紹介されている。これなら意識的に取り組んでいける。
いまは毎日コードを書いているので、読んでいていろいろ想像できた。人が読むことを考えると、丁寧に書くよね。仕事で書くコードは全部コードレビューされるし、読みやすいコード書きたい。
本書の解説にこんな一文があった。
「忘れても見たら簡単にわかるように書いておくんですよ。」
「情けは人のためならず」と一緒で、人のためではなく自分のためにリーダブルコードを書きたい。
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
posted with amazlet at 13.01.12
関係ないけど、ここで書いている文章はリーダブルじゃないことが多いと思う。それでいいと思っていて。もっと一文を短くしたり、主語を明確にすることで読みやすくなるだろうけど、あえてしていないこともある。
でも外部媒体で記事を書くときは、わかりやすくて伝わる、そして楽しい文章を心掛けている。
