リーダブルなコードにする

リーダブルなコードにするとは、コードを読んで理解する時間を最短にするということ。

優れたコード=短いコード ではない

他人のためだけでなく未来の自分のためでもある

名前に情報を詰め込む

tmp, retvalなどの汎用的な名前は避け、短すぎたり長すぎる名前も避ける。
→エディタの単語補完機能があるので、名前の長さで開発スピードが落ちることはない。

名前の長さはスコープに強く依存する

スコープが小さければ短い名前でもいい。
メンバ変数やグローバル変数であれば名前に十分な情報を詰め込むべき。

目にも優しいコード

原則

• 読み手が慣れているパターンに
• 一貫性のあるレイアウトに
• 似ているコードは似ているように
• 関連するコードはまとめてブロックに

class Logger {
    ...
};

class Logger
{
    ...
};

上記は完全にエンジニアとしての好みによる書き方の違いだが、これらも一貫したレイアウトの原則に従ってどちらかのスタイルのみを使用するべき。
プロジェクトによっては間違ったスタイルを使用している場面もあるが、それはプロジェクトに従うべきであるとのこと。

コメントは本当に必要か

リーダブルなコードとは読み手の理解する時間を最短にすることであった。
ひどいコメントは貴重な理解するための時間を奪う。
変数と同じで、コメントにも必要な情報を詰め込む

コメントすべきではないこと

• コードからすぐに読み取れること
• ひどいコードを補う補助的なコメント → コメントに頼るのではなくコードを修正する

コメントすべきこと

• なぜコードが他のやり方ではなくこうなっているのか
• コードの注意書きをする(TODO:, XXX: の記法を使って)
  • TODO: あとで手をつける
  • FIXME: 既知の不具合があるコード
  • HACK: あまり綺麗じゃない解決策
  • XXX: 危険！ 大きな問題がある
• 定数の値にまつわる背景

条件式も読みやすく

if length > 10:

if 10 < length:

であれば読みやすいのは前者。
なぜならば、評価の対象(length)が最初に目に入るからである。

time_str += (hour >= 12) ? "pm" : "am"

return exponent >= 0 ? mantissa * (1 << exponent) : mantissa / (1 << -exponent);

三項演算子は、前者は読みやすいが、後者は読みにくくなってしまう。
これが1行で記述することがリーダブルコードとはならない例である。

その他にもdo-while、条件文のネストは避けたほうがよい。

低レベルの問題はモジュールに切り分ける

原則

• プロジェクトと無関係な問題は汎用コードとして切り分けるべき(→複数のプロジェクトで再利用)
• 既存のインターフェースが使いづらければラップするべき

読んだ後にやるべきこと

• 実際にやる
• 当たり前にする
• コードで伝える

読みやすいコードを書く、忘れてもいいコードを書く。