リーダブルコードとは？（命名規則編）

リーダブルなコードとは

リーダブルなコードは、読み手が理解する時間を最短にすることができるコードである。

反省点

なんとなくで短いコードを使っていた

本書を読む前では、短い表現を見つけたらなんとなくスマートに見えるからという理由で使っていた。しかし良いコードというものはパフォーマンスがよく、読み手が理解するのに時間がかからないこと目指すべきである。もちろんこれはチームの他のメンバーだけでなく未来の自分にも言える。
コードの短さ <<　読み手が理解するのにかかる時間の短さ
である。

変数名が具体的ではなく短すぎた

変数名からは内容が想像しにくいような曖昧なワードを使用していた（get,filterなど）。変数名は短いコメントのようなものなので、中身が想像できないようなワードを使うのはよくない。また、変数名を短くしすぎてしまっていたせいで中身がわかりにくいこともあった。


例えば、gem deviseでは

def after_resending_confirmation_instructions_path_for(resource_name)
      is_navigational_format? ? new_session_path(resource_name) : '/'
    end

といったメソッド名が使われている。
特にスコープの範囲が広い時ほど変数名は内容の理解のスピードを最優先すべきで、短ければスマートというわけではない。

とにかくコメントを入れることを避けていた

コメントを入れるとその分コメントを読む時間がかかるが、一方でコード内容を理解するスピードを早めるのであれば当然コメントすべき。トレードオフを考えることが大切で、とにかくコメントを抜けばいいわけではない。

命名、コメント時の注意点

曖昧なワードを避ける

例)filter
filter(範囲)というメソッドの場合、範囲を除外するのか範囲を選択するのか非常にわかりにくい。よってselectやexcludeといった具体的なワードの方が良い。

関数名、変数名で説明した後、読み手の理解を助けるコメントをつける

ダメな名前のコードを書いてコメントで説明するよりも、コード自体をわかりやすくした方が良い。

コメントは抽象的な説明じゃなく実例でも良い

抽象的すぎる説明よりもいっそ引数と返り値の実例を書いた方がわかりやすい場合がある。

目的ではなく動作を書く方が良いことがある

# ファイルの行数を数える
よりも
## /nの数を数える
の方がロジックがわかりやすい

後者の場合、""は一行に含めるか・最後の改行は一行に含めるか、などといった疑問を持つことなくコードを理解できる。

まとめ

初心者のうちはパフォーマンスを意識することが難しく、悪いパフォーマンスのコードの指摘をもらって修正する流れになると思う。であれば指摘までのスピードを早めるために読んでからの理解スピードが早いリーダブルなコードを書くことに集中することがチームを円滑に、かつ自信の成長スピードを早める。