こんにちは、マスラオです。
今回は、かつてSEとして働いていた時にめちゃくちゃお世話になった本を紹介します。
SEが遭遇する困難の第一位が、「他人が書いたコード」、
そして第二位が、「自分が書いたコード」です。
配属当初、「数ヶ月前に自分が書いたコードさえ解読できないのに、他人が書いたコードなんて読めるかい！」状態だった私ですが、
『リーダブルコード』を読んでから実装の腕がメキメキ上がり、他人のコードもスラスラ読めるようになりました。
コーディング規則は、この本を読んでおけばとりあえず間違いないです。
こんな人にオススメ
この本を読む上で、前提知識はそれほど必要ありません。
If文・for文など基本的な構文が使え、オブジェクト志向についてなんとなく知っているレベルであれば読めます。
ちなみに私は未経験のSEとして採用され、1ヶ月程経った時に読みましたが、
その時は難しく感じ、その後3ヶ月くらい経ってから読んでみたらスッと読めました。
この本は、以下のような人にオススメです。
・「とりあえず動く」コードが書ける人
・コーディングスピードを上げたい人
・他人の書いたコードをスラスラ読めるようになりたい人
本書の中から、個人的に感銘を受けた、明日からすぐに使える部分を抜粋してご紹介します。
短いコードが良いコードとは限らない
2000行のクラスのほうが5000行のクラスよりも理解するまでにかかる時間は短いはずだ。
でも、短ければいいってもんじゃない！このような1行のコードは、
assert((!(bucket = FindBucket(key))))( || !bucket -> IsOccupied());
以下のような2行のコードを理解するよりも時間がかかることが多い。
bucket = FindBucket(key);
if (bucket != NULL) assert(!bucket -> IsOccupied());
上のコードはあるあるですね。
コーディングはパズルのような面白さがありますが、まとめすぎるとわかりにくくなる典型です。
コーディングにおける「シンプル」とは、コードの短さではなく理解のしやすさです。
コードは短くしたほうがいい。だけど、「理解するまでにかかる時間」を短くするほうが大切だ。
「何のためにコードを短くするのか」という視点が重要です。
コードを短くするのは、読む時間を短縮するためですよね。
無理やり短くした結果、難解なコードになってしまっては本末転倒です。
名前に情報を詰め込む
例えば、「get」はあまり明確な単語ではない。
def GetPage(url):
・・・
「get」という単語からは何も伝わってこない。このメソッドはページをどこから取ってくるのだろう？ローカルキャッシュから？データベースから？インターネットから？インターネットから取ってくるのであれば、FetchPage()やDownloadPage()のほうが明確だ。
日本人にとっては、英語で命名するのは少し難しいかもしれません。
GetとFetchの区別なんて、プログラミングしていなければ意識することはありません。
頻出する単語はあるので、自分の中の辞書を少しずつ厚くしていくしかないです。
・明確な単語を選ぶ。ー例えば、Getではなく、状況に応じてFetchやDownloadなどを使う。
・tmpやretvalなどの汎用的な名前を避ける。ーただし、明確な理由があれば話は別だ。
・具体的な名前を使って、物事を詳細に説明する。ーServerCanStart()よりもCanListenOnPort()のほうが明確だ。
・変数名に大切な情報を追加する。ーミリ秒を表す変数名には、後ろに_msをつける。これからエスケープが必要な変数名に位は、前にraw_をつける。
・スコープの大きな変数には長い名前をつける。ースコープが数画面に及ぶ変数に1〜2文字の短い暗号めいた名前をつけてはいけない。短い名前はスコープが数行の変数につけるべきだ。
・大文字やアンダースコアなどに意味を含める。ー例えば、クラスのメンバ変数にアンダースコアをつけて、ローカル変数と区別する。
ちなみに、以下のサイトでは、日本語を入力すると自動で変数・メソッド名をつけてくれます。
一単語ずつググるよりも大分速いので、命名の参考にするにはオススメです。
コメントでコードの説明をしない
以下のコードに書かれたコメントには価値がない。
// Accountクラスの定義
class Account {
public:
// コンストラクタ
Account();
// profitに新しい値を設定する
void SetProfit(double profit);
// このAccountからprofitを返す
double GetProfit();
};
新しい情報を提供するわけでもなく、読み手がコードを理解しやすくなるわけでもない。全く価値がない。
綺麗なコードにしようと思い、1行ずつ丁寧にコメントを入れていくのは逆効果です。
私が新人のときの上司は、「コメントを書かなくても良いコードを書け」と言っていました。
実際、まったくコメントのないコードを書くことは難しいにしろ、情報量0のコメントは書かない方がマシです。
では、価値のあるコメントとはどのようなものでしょうか。
たとえば、考えを記録する「コメンタリー」的な意味のコメント。
// このデータだとハッシュテーブルよりもバイナリツリーのほうが40%速かった。
// 左右の比較よりもハッシュの計算コストの方が高いようだ。
あるいは、シンプルにToDoを記載するコメント。恥ずかしがらずに書きましょう。
// TODO: もっと高速なアルゴリズムを使う
・・・
//TODO(ダスティン): JPEG以外のフォーマットに対応する
あとは関数の内容を要約するコメント。
長い関数に要約コメントがついているとありがたいですね。
# 顧客が自分で購入した商品を検索する
for customer_id in all_customers:
for sale in all_sales[customer_id].sales:
if sale.recipient == customer_id:
・・・
まとめ
熱意のない人も含め、大体のエンジニアが読んでいるのが、『リーダブルコード』です。
最新技術でも枯れた技術でも、共通して重要になるのがコーディングのお作法。
エンジニアの先輩方と対等に会話するための必携本です。