きれいなコードを書く4 - ポリウッドザコゲボク

やるぞ。

前回のまとめ

第三章　誤解されない名前
解釈が分かれる可能性がある名前は徹底的に排除していこうな、という話。
・filter()
フィルターをかけた結果、閾値のどっち側が残るのか分かる名前にしたほうがいいね
・Clip()
これも同じで、閾値「までを」クリッピングするのか、閾値「より小さい」ところをクリッピングするのか分かるようにしたいね
・限界値を含めるときはminとmaxを使う
「1~10番目まで〇〇する」みたいな場合、10を格納する変数（定数）はMAX_LENGTHみたいにMAXをつけよう。これも以上か未満か、の時に困らないため。
最小値の場合も同様にMINをつけてあげような。
・範囲を指定するときはfirstとlastを使う
これもminとmaxと同じ。

二章をまとめると、「中身が分かりやすくなるように具体的な単語を使っていこうな」って話でした。
三章では「中身分かるように気を利かせたつもりでも、解釈が複数存在するかどうか気を遣おうな、って内容。

包含/排他的範囲にはbeginとendを使う

この節、少し引っ掛かったので丁寧めにかく。
6月21日の間に発生したログをファイル出力する、というメソッドを作ったとする。
メソッドの呼び出し時に、引数を
ExportLog("Jun 21 12:00am","Jun 21 11:59pm")
とさせるのはちょっとややこしくて嫌なので
ExportLog("Jun 21 12:00am","Jun 22 12:00am")
みたいに呼び出せるように作ったとする。つまり「排他的範囲指定」をするように作ったわけだ。
このメソッドを定義する際の『仮引数』をどうしましょうかという話。
結論から言うと、包含でも排他でもbeginとendを使うのがベターらしい。英語ではendが排他・包含どちらにも使えるからしゃーない、という話だった。

ぶっちゃけ「結論出ないならこの説明いります？」と思ったが、「結論が出ない」という結論を知っておくことで無駄に考える時間が省けるということだろう。

ブール値の名前

trueとfalseを格納する変数は絶対と言っていいほど出てくると思うが、これに意味を設定しようという話。
例えば、check_DBConnectみたいなbool値を格納する変数があったとする。
これが「trueのときチェックを実行する」のか、「DBへの接続状態をチェックした結果」が入っているのか、ぱっと見では分からない。
前者であれば、needCheckingDBConnectとかにして、後者ならDBConnectingStatusとかにしたほうが幾分分かりやすい。

また、変数名に否定形を使うと一回脳内で逆に変換しなきゃいけないので辞めたほうがいい。
DisconnectingDBStatusだったら「『DBに接続してない』が『false』だからDBに接続『してる』ってことか！」みたいなね。
やめよう。脳は必要最低限しか使わないようにしよう。

ユーザの期待に合わせる

これは「プログラマの一般認識」から逸脱するな的な話なので、一般認識が無い自分だとよくわからない話だった。
例として、getCsvData()みたいにしてたら、csvファイルを「単体で」読み込むと思ってしまうので
このメソッドに「特定フォルダ配下のcsvファイルすべてを読み込み、一列目の値がAのもののみ引っこ抜く」みたいにすると想像以上に処理に時間がかかるのでやめとこうな、といった感じ。
初見で「ああこう動くんだろうな」っていう印象から逸脱するようなことを書くな、という話。

複数の名前を検討する

「ここまでの話全部これじゃね？」って感じがするが、名前を考えるときにはいくつかの候補を上げようという内容だ。
上がっていた実例を自分風にアレンジするとこうなる。

実行した端末が接続しているプリンタ情報を出力するメソッドを作ったとする。
ExportPrinterInfo(filePathToExport)
みたいな感じで。出力先のフォーマットによって、別々のファイルパスを定数に格納していたとする。
EXPORT_FILE_TEMPLATE = "c:\~~";
EXPORT_FILE_NUM1 = "d:/~~"
みたいな・・・ちょっと設定苦しいけど・・・

で、このとき「Templateがデフォルトで使うやつ」なのか、「Templateに設定されたパスをお手本にして他の設定値も書いてね」的な意味のTemplateなのか分からんじゃん、みたいな…
こういうのを防ぐためにいろんな名前を考えましょうね、ということらしい。

今日はここまで

本の内容を丸パクリすると申し訳ないし、何かしらで罰せられるかもしれないので自己流に変更して書いていることが多いのだが、
今回みたいに「プログラマあるある」が基になっていると例を考えるのに苦労するな・・・
さておき、第四章では「美しさ」の話に入る。何かを設計する人って手法に対して「美しくない」みたいなこと言うよね。あれなんなのって思ってたけど、次で分かるかな？