きれいなコードを書こう2

昨日の続きから。
軽く振り返っておこう。

前回までのまとめ

・コードは「短く書く」のではなく「理解する時間が短くなるように書く」が大原則
・明確な単語を選ぶ
できるだけ具体的な情報を組み込んだ名前を付けよう。例)getは抽象的過ぎ→downloadとかにする
・汎用的な名前を避ける
retval(return value)では何が返ってくるのか分からない。意味を含ませること。例)retval→sum_examscore
※寿命の短い(数行さかのぼれば分かるもの)は別にいい。tmpとか。
要するに意味もなく中身が推測できなくなるような命名をするなということ。

余談だが、僕が高校三年生の時に化学を担当してくれた先生は、毎回授業の最初に「前回のまとめ」を生徒自身に口頭で述べさせていた。
これめっちゃ利くのでおすすめ。ちなみに僕は50分授業のうち45分寝ていたため目の敵にされていた。(一か月くらい経ってから卒業まで、最初から最後まで自主的に立ったまま授業を受けた。)

さて、ここからは今回のまとめだ。

抽象的な名前よりも具体的な名前を使う

職場で書いたコードではメソッド名にReadIni()みたいなのを使っていた。
あ~iniファイルを読むんですね~ってなるけど、「型は?」「何の情報?」「対象のiniは?」みたいな情報が分からない。
より具体的にするならReadFTPSvrNameIni()(FTPサーバ名を取ってくる)とかの方がいい…っていうことが本に書いてあった。(解釈が正しいかは分からない)

もう一つ、本には「直行する概念は無理に一つにまとめようとせずに、別々に使えるようにするといい」と書いてあった。
例として、「あるオプションコマンドにデバッグ情報を印字する(ログ出し)機能と、ローカル用のデータベースを設定する機能を持たせようとしたら?こういうときは命名の軸がぶれてしまうのでオプションは二つに分けよう」というようなことが書いてあった。
「一つにまとめると便利っぽいけど、意味が分からなくなったら元も子もない。それなら分けて、意味がぱっと分かるようにしよう」という話だ。なんかこう、オブジェクト指向っぽいですね(わかってない)

接尾辞や接頭辞を使って情報を追加する

ここには「名前にどんな情報を追加するか」という例が紹介されていた。

1. 単位
ミリ秒ならms、バイト数ならbyteとかね。

2. その他の重要な属性
例えばパスワードなら暗号化されているかどうかは重要なポイントになる。
passwordという変数名よりplaintext_passwordとかの方が扱いが分かりやすい。
文字コードがutf8のhtmlならhtmlよりhtml_utf8の方がいい。

このようにサブ情報的なものを追加することはコードの理解を速くする助けになる。

名前の長さを決める

なっげ~名前は嫌われるけど、それは「入力しにくいから」じゃない。今は単語補完機能はほとんどの開発環境に実装されている。
問題は「不必要に」長いやつだ。じゃあその必要性はどう判断すればいいのか?
スコープが一つの判断基準になる。たとえば一つのループ処理やif文の分岐処理内で定義された変数であれば、内容を把握しやすいのでクソ短くても大丈夫だ。

if ( dayOfTheWeek == "Friday"){
    string n;
    n = SearchTokyoTorikizoku();
    console.writeline(n);
}

めちゃ適当だがこれだったら「ああ、鳥貴族の店舗名かなんかが格納されるんだな」みたいになるので別に問題ない。(ないか?)
だが、このnがグローバル変数だったら他のどこで呼ばれるか分からんし、格納するのが店名なのか店番号(int)なのかとかが分からないのでもうちょっと長い名前で定義したほうがいい。
スコープ範囲=未知との遭遇率と考えて、未知度合いをコントロールする。

さて、一方でイミフな短いやつもある。
以前見たやつだと「CV」とかね。csv valueのことだった。イミフ。
省略していいのは業界の共通認識のものだけだ。stringならstr、documentならdocみたいな。
当たり前のように外界に独自の略語をまき散らしていいのは女子高生だけだ。

上記を満たしつつ、無くても意味が伝わる場合には語数を減らそう。
convertToStringはtoStringでも意味がわかる。

名前のフォーマットで情報を伝える

僕もすでに何度か使っているが、アンダーバーやダッシュ、大文字で名前に情報を組み込むこともできる。
定数なら全部大文字、変数は頭だけ小文字で単語の初めは大文字にする、メソッド名は頭も大文字にする、といったルールが決まっていれば、名前を見ただけでそれが何をしているものか理解できる。
例)
NUMBER_OF_CAR→車のナンバーが定数で格納されてんだな
wheelAmount→タイヤの数かな?変数に入ってるからどっかで取得でもしてんのかな
DriveHighWay→高速道路に乗るためのメソッドかな
みたいな。

ただ、これをする際は「組織内でフォーマット規約をばっちり決めて共有しておくこと、厳守すること」が必須になる。一人の無法者のせいで秩序が完全崩壊することはままあるので注意する。
ちなみに今僕が務めている会社ではフォーマットがどこかに存在するらしいが、新任にそれが共有されてない。なんなんだ。

今日はここまで

「名前に情報を詰め込むようにしろ」「具体的なものにしろ」「長さが問題なのではなく『無意味に』長さが変わっているのが問題」「秩序立てることで表現の幅が広がる」といったのがこの章の内容だった。
次回は第三章、「誤解されない名前」だ。引き続きしっかり勉強すっぞ。