【2章】変数を我が子のように扱う。そしたら命名するのも慎重になるのではないか。@リーダブルコード

家計簿をつけているのですが、コンビニで買うお菓子の散財率が高過ぎる。節約するならこういう所から削っていかないとですね。

2章から始まる第一部のテーマは「表面上の改善」です。変数名を変更したり、簡潔なコメントをつけたりと、すぐに良くできるところから変えていこうという内容です。

コードの改善も節約も塵も積もれば山となる！小さなことを積み上げていきましょう。

2章：名前に情報を詰め込む

一章と共通しているのは「知らない人がコードを読んでも短時間で理解できること」です。曖昧な命名をするのではなく具体的な名前にすること。短くても意味が伝わる単語を選ぶこと。そのような名前をつけることで、知らない人が見ても理解がしやすいコードになります。

◼️明確な単語を選ぶ

get()やsize()はよく使われる単語だがあまり"明確な言葉"ではない。get()するのはデータベースから？インターネットから？size()は高さのこと？数のこと？

例えば、単語「make」は「create/setup/add/new...」など色々な言い回しがある。状況に合わせて、明確かつ正確な言い回しを。

動作一つでも色々な言い回しがあります。
例えば「作る」を表現するときいくつ言葉を思いつくでしょうか。

類語辞典で調べてみると「作る/制作する/ 組み立てる / 構成する/設計する /建築する...」などなど多くの言葉が出てきました。新しく"作る"のか、既存のものを"組み立てる"のか用途に応じて使い分けるように、メソッドの処理内容に応じて命名するということでした。

【汎用的な名前を避ける】
いい名前とは、変数の目的や値を表すもの。

【汎用的な名前の使用例】
「tmp」
・使用するのが数行
・一時的な保管に使用

「ループイテレータ」
・複数のイテレータを使う場合は、明確な名前をつける

【具体的な名前をつける】
抽象的な名前ではなく、変数の目的や処理内容によって具体的な名前をつけるべき。

・名前に情報を追加する
「値の単位」や「重要な属性」を追加する。

例えば、パスワードを暗号化する場合、

before_password
↓
暗号化
↓
after_password

ではなく、

plain_password
↓
暗号化
↓
hashed_password

のように変数に属性をつけるようにする。

ここで、単位や属性をつける基準は変数の意味を取り違えてしまったときにバグが生じてしまうようなところに使うというようにありました。初めてコードを見る人でも、単位が分かれば必要に応じて計算することができますね。

◼️名前の長さを決める

名前の長さはかなり迷います。どこまで詳しく書くべきなのか、説明的をつけた単語が良いのかなど今日も迷いました。

これについては、ガイドラインがあるらしいです。

【スコープが小さければ短くてもいい】
その変数の有効範囲が小さければいい。

【長い名前は問題じゃない】
単語補完を使えばいい

【頭文字&省略形】
プロジェクト固有の名称でなければ、「String→str」「 Document→doc」など省略したり、頭文字を使う

【不要な単語を投げ捨てる】
「ConvertToString()→ToString()」にしても理解ができる。単語を切り捨てて意味が通じるか考えてみる

一章にもあった「読んで理解できる時間を短くする」ということに共通していますね。短ければ読む量が少なくなるので理解できる時間は短くなりますが、あまりに短すぎると理解するのにかかる時間が長くなってしまう。コードを書いた後に時間を置いて、改めて見直したときに理解できるかどうか試してみると良さそうです。

二章は「名前に情報を詰め込む」でした。
目的や処理内容に応じて伝わる名前をつけること、単位や属性をつけて具体的な名前にするなど、すぐにできる改善点を学びました。ちりつもでコードを良くしていきましょう！

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)