きれいなコードを書こう3 - ポリウッドザコゲボク

やるぞ。

前回までのまとめ

第二章は「名前に情報を詰め込む」という内容だった。
・明確な単語を選ぶ
getとかじゃなくdownloadとか、対象や目的が推測しやすい言葉を使う。
sizeじゃなくHeightやMemoryBytesとか中身が分かるようにする
・汎用的な名前を避ける
retvalじゃなくてexamScoreとかね。
ただし寿命が長くないものはtmpとかでもいい。
大事なのは理由もなく汎用的な名前を使わないということ。
・具体的な名前を使う
メソッド名であれば「それが何をするものか」がはっきりわかるようにしてあげたほうがいい。
SaveDatabaseでなくKickCheaterとか。あと、複数の機能を持たせた結果、名前に関係ない概念の動作が入るくらいなら分離してやること。
サッカーゲームでKickBallにヘディングやスローイン機能がくっつくくらいならHeadingBallとかThrowBallにしたほうが分かりやすい。
・名前に情報を詰め込む
変数に計測可能な値を突っ込むならその単位を書くといい。timeForWaitならtimeForWait_msみたいな。
もう一つの観点として、危険や注意を喚起する情報を名前に入れることが挙げられていた。
・名前の長さを決める
長い名前が問題ではなく、無意味に長いことが問題。
無くてもいい情報は名前から省く。スコープが小さいならすぐ辿れるので長い名前にしなくていい。略称は一般的なものだけ使うようにする。
・名前のフォーマットで情報を伝える
フォーマット規則をチームで共有しておけば、名前からその実体を特定できる。アンダーバーや大文字、小文字など。
言語によって使えるフォーマットは変わると思うが、大事なのはプロジェクトで一貫性を持たせることだ。

第三章　誤解されない名前

はい、まとめが長くなったが、ここからは新しい内容だ。
名前が違う意味に勘違いされないかをよく考えましょうね、という章らしい。
具体例が色々載っているので、「禁止ワード」くらいの感じで覚えていきたい。

filter()

「フィルターした結果なにがでてくるの？？？」っていうね。
filter("Hz <= 800Hz"）みたいなやつだったら800Hz以上がフィルターされるのか、800Hz以上をフィルターするのか分からん。
Select()だったら800Hz以下をフィルターするんですね～って分かる。
微妙な差だし、「分かんだろ！」ってなりそうだけど、この『きっと』伝わるみたいな不確定要素を徹底的に探す、というのがこの章の要点だ。

Clip(text,length)

はい。テキストの「始めから」何文字か、「終わりから」何文字か分からんていうことやね。
あと、lengthもmax_lengthとかの方がいいよね。

限界値を含めるときはminとmaxを使う

「何文字以上の入力禁止」とかの制約がある場合、上限値をLENGTH_LIMITにしていたら
enterChar <= LENGTH_LIMITとするのか
enterChar < LENGTH_LIMITとするのかが分からない。
こういう場合はMAX_LENGTH_LIMITとしてあげれば「ああ、最大でそこまでなんですね」と分かるので書き間違えなくて済む
enterChar <= MAX_LENGTH_LIMITが正解だ。

範囲を指定するときはfirstとlastを使う

上述の「範囲」に関する命名時の工夫は他にも手段がある。
配列の1~10番目までを対象に何かをする場合、startNum=1, stopNum=10とすると
ループ処理において10になったらやめればいいのか、10までやるのかが分かりにくい。
ということでfirstNum = 1, lastNum=10とすれば10が最後の要素だと分かる。

一端ここまで

ちょっと他にも一本ブログを書いたので疲れてきた。
脳のキャパ的に一度ここで止めておく。