はじめに
次のプロジェクトでリーダブルコードの概念を重要視しているという噂を聞きつけたのでまとめます。
リーダブルコードは「高品質なソースコードを書くためのルールやテクニック・概念」が記載されています。
実際に手を動かしながら理解できるものもあれば、すぐに実践できるものもあります。
とりあえず知っておいて、良コードとはどういうものかの基準を知ることができるのでITエンジニアは一度読んでおいた方が良い本です。
リーダブルコード より良いコードを書くためのシンプルで実践的なテクニック （Theory in practice）
変数名・メソッド名・クラス名はわかりやすい名前にする
これはこの目的で使うメソッドだよ、この変数はDBのこのカラムから取得したものが入っているよ、
という感じで変数名から何者なのか、どんな使い方をするものなのかを想像できればＯＫです。
色んな意味と捉えられる名前はやめましょうというルールもあるので、
とりあえず codic を使えばよいと思います。
言語やプロジェクトの命名規約に従う
UPPER_SNAKE_CASEだから定数だよね、っていう感じで一目で何者かが分かるのでしっかり守りましょう。
短く分かりずらいソースよりも長い分かりやすいソースをかこう
短く書けるのは気持ちいいけど、少し長くてもすぐに内容を把握できる方がよいです。
変数名も長くても何者なのかが分かる方がよいです。
インデント・改行・段落をつける
インデントがずれていると壊滅的に読みずらくなるので守りましょう。
改行は一貫したルールをもってやりましょう。
段落は処理毎でまとめるとよいです。
コメントは必要なことだけ書く
必要なコメント
・ソースを見ても分からないこと
・ソースを見て疑問に思うであろうこと
・todoやfixmeなどタスクや課題
不要なコメント
・ソースの説明（コメントを書かないと理解できないソース事態がよくないという考え方）
※ただし分かりずらい処理内容を書くことはありです。
IF文はこう書くとよい
条件式は左辺が変動する値、右辺が固定の値の方が読みやすい
// 読みやすい
if(変数 == 10){
}
// 読みにくい
if(10 == 変数){
//処理
}簡単な条件から書く
// 読みやすい
if(a == 10){
//処理A
}else if(a < 9 || a > 11){
//処理B
}
// 読みにくい
if(a < 9 || a > 11){
//処理B
}else if(a == 10){
//処理A
}三項演算子は基本使わないが、わかりやすくなるようなら使う
if(isHungry){
hoge = "お腹すいた";
}else{
hoge = "お腹いっぱい";
}
// 三項演算子でかくとこうなる。わかりやすい。
hoge = isHungry : "お腹すいた" ? "お腹いっぱい";ループはこう書くとよい
条件は最初に書いた方がわかりやすい
// 読みやすい
for(a > 10){
//処理
}
// 読みにくい
do{
//処理
}whlie(a > 10)なるべくネストしない
ネストしない方が良いことはみんな分かっていると思います。
なのでどうやって回避するかを学んでおく必要があります。
returnはメソッド内にいくつあってもよい
returnがいくつあるかよりも、大事なことは読みやすいかどうかです。
説明変数でわかりやすくできる
説明変数とはその名の通り、変数自体を説明する変数のこと。
冗長になるという人もいるますが、実際これがあるととっても読みやすくなります。
// 説明変数がないバージョン
// 何かとtanakaが一致していればifに入るのか。。。何と比較しているんだ？
if(line.split(':')[0].toString() == "tanaka"){
・・・
}
// 説明変数があるバージョン
// 名前がtanakaならif文にはいるのね。
String userName = line.split(':')[0].toString();
if(userName = "tanaka"){
・・・
}要約変数でわかりやすくできる
説明変数と似ていますが、処理の結果を変数に入れることでわかりやすくなります。
有効なやり方なので覚えておく価値ありです。
// 上記の説明変数の例を使う
// 要約変数があるバージョン
// if文の判定はadmin権限のユーザーかどうかを見たいことが伝わる。
String userName = line.split(':')[0].toString();
boolean adminUser = userName == "tanaka" : true ? false
if(adminUser){
・・・
}論理式を変換する方法を覚えておく
本書ではド・モルガンの法則のみを紹介していますが
「論理式 変換」とかでググると色々でてくるので覚えておくとたま～につかえます。
// 同じ論理式
if(!(isDelete1 || isDelete2))
if(!isDelete1 && !isDelete2)不要な変数を削除する
変数がたくさんあると覚えておきながらソースを読むことになります。
要は頭のメモリを使うことになるので頭にも心にも負担がかかってしまいます。
不要な変数（なくても読みにくくならない変数）は作らないようにしましょう。
説明変数や要約変数を使うことと反対のことを言っていると感じるかもしれませんがそうではありません。
変数がたくさんあることで読みにくくなることを知っておくべきです。
変数のスコープを縮める
これも頭のメモリをひっ迫する原因になります。
スコープが広ければ広いほど変数を気にかけておく必要があります。
適切なスコープで変数を使うようにしましょう。
言語によってスコープの範囲が異なる
Java・C#ではブロック内で生成した変数はブロック内のみで使えます。
Python・JavaScriptではブロック内で生成した変数はブロック外でも使えます。
それゆえ意識的に変数名の衝突を起こさないような実装をする必要があります。
機能毎または目的毎にメソッド化しよう
やりたいことがはっきりした処理は読みやすいです。
読みやすくできるレベルまで分割したり、メソッド化しましょう。
ただしメソッドを作りすぎるとメソッドからメソッドにとびまくるので読みにくくなってしまいます。
小さすぎるメソッドを複数作ることは逆効果になります。注意しましょう。
共通メソッドをつくろう
プロジェクト全体で使える処理をまとめられるととても良いです。
提供されている既存のメソッドを作り替えよう
既存で提供されているメソッドでも使いずらいものが多々あります。
そんなときは自分でメソッドを作って使いやいように作り替えてしまえばよいです。
1行で行うタスクは1つずつ
一行に色々な処理を詰めると読みにくくなります。
処理ロジックを書き出すことで読みやすいコードにする手法
やりたいことを日本語で書きだすことでタスクを分割したり、処理の段落をまとめたりと読みやすくすることが出来ます。
最も読みやすいコード＝何も書いていないコード
設計段階で活かせる内容だと感じました。
①本当に必要な機能なのかを考える。実は不要な機能がまざっていないか。
②コーディングではなく別の機能で実現できないか。
②の例としては、例えばAPIを定期的に実行する必要があるとします。
フレームワークの機能でタイマーを仕掛けてhttpdのライブラリを読み込んでAPIを叩く、、、とすると30-40行くらいにはなりそうです。
そんな事せずともLinuxのcronという機能でculrコマンドを実行すれば実現できます。
これでソースコードを作らずとも要望を満たすことができました。
ライブラリのAPIを少しずつ読んでおく
ライブラリで提供されて入れば自分で書く必要がありません。
全てを覚えておく必要はなく、「あ、この処理に使えそうなメソッドが用意されていたかも？」と思い出せればよいです。
終わりに
例がないと理解できないものもあったかもしれません。
本書では例を用いてわかりやすく記載されていますので、他のエンジニアより一歩先を目指したい方には読破必須な本だと感じました。
コメント