リーダブルコードを読む part3
こんにちはかわです。
アドベントカレンダー１８記事目書いていきます。
前回の続きです。
3章 誤解されない名前
名前が「他の意味と間違えられることはないだろうか？」と自問自答する
1 と 2
誤解を招く名前は変更する
例：Clip(text, length)
def Clip(text, length) ・ ・ ・
このままだと
- 最後からlength文字を削除
- 最大length文字まで切り詰める
のかわからない
疑問を抱かせる名前はだめ
max_charsにすると効果的
3 限界値を含めるときはminとmaxを使う
限界値を明確にするため、名前の前に
max_
min_
をつける
4 範囲を指定するときはfirstとlastを使う
範囲を指定する際に「start」「stop」を使うことがあるが、
stopは複数の意味に解釈される事がある。
包含的な範囲（終端を範囲に含める）なら、firstとlastを使う方がいい
5 包含/排他的範囲にはbeginとendを使う
プログラミングの命名規則では、包含/排他的範囲にbegin endをよく使う
endは少し曖昧だが、英語にはこれに置き換わる語がない（らしい）
beginとendを使うことが最善であるらしい
6 ブール値の名前
ブール値の変数やブール値を返す関数の名前を選ぶ際は、
true falseを明確にすべし
trueかfalseのどちらが正しいかをそれとなくにおわせる必要がある
is や hasを使いブール値だとわかるようにする
否定形は避ける
7 ユーザの期待に合わせる
ユーザが先入観を持っているために誤解を招くことがあるため、
誤解されない名前に変更する必要がある。
例としてget*()をあげると、
コストが低いものだという先入観がある（らしい）。
もしコストが高いのであればこれを明示される名前に変えるべき。
8 例：複数の名前を検討する
名前を決めるときは、複数の候補を検討すべし
最善の名前とは、誤解されない名前である
以上
リーダブルコードを読む part2
こんにちはかわです。
アドベントカレンダー１７記事目です。
続きを書いていきます。
2章 名前に情報を詰め込む
1 明確な単語を選ぶ
「get」はあまり明確ではない
例 def GetPage(url):
・・・
これはどこから取ってくるものなのか？
インターネットから取ってくるのであれば
「Feach」「Download」のほうが明確
例 Size -> Height NumNodes MemoryBytes 等
気取った言い回しより明確で正確に
2 tmpやretvalなどの汎用的な名前を避ける
tmp・retval・foo この３つより
目的、実物の値を表した名前を選ぶ
retvalには「戻り値」という情報しかないためプラスαの情報を付加する
tmpという名前は、生存期間が短く、一時的な保管が大切な変数にだけ使用
ループイテレータ（i, j, k, iterなど)が複数ある場合、
説明的な名前にするとバグが目立ちやすくなる
3 抽象的な名前よりも具体的な名前を使う
例 ServerCanStart() -> CanListenOnPort()
任意のTCP/IPポートをサーバがリッスンできるかを確認するメソッド
変更後のほうがメソッドの動作をそのまま表している
4 名前に情報を追加する
名前は短いコメントのようなもの
大切な情報があれば「単語」を変数名に追加する
値の単位や危険や注意を換気する情報も追加したほうがいい
5 名前の長さを決める
スコープが小さければ短い名前でいい
->スコープが大きいならば長い名前を
エディタの「単語補完」機能を使用すべし
頭文字や省略形を使用する場合、誰が見ても明確に
不要な単語は取り除く
6 名前のフォーマットで情報を伝える
いろいろなフォーマットがあるためチームで統一して書くべし
大文字やアンダースコアに意味を持たせる
以上
リーダブルコードを読む part1
こんにちはかわです。
アドベントカレンダー１６記事目です。
今回は
この本を読み進めて章ごとに要約していきたいと思います。
1章 理解しやすいコード
1 優れたコードとは？
「簡潔」と「安心」はどちらが大切か？
Ruby 2.4.0
//九九の表示
//簡潔例
1.upto(9){|i|1.upto(9){|j|puts"#{i} * #{j} = #{i * j}"}}
//安心例
for i in 1..9 do
for j in 1..9 do
result = i * j
puts"#{i} * #{j} = #{result}"
end
end
2 読みやすさの基本定理
コードは他の人が最短時間で理解できるように書かなければいけない
3 小さいことは絶対にいいこと？
「理解するまでにかかる時間」を短くすることが大切！！！
コードは短ければいいということではない。
コードを短くし、理解に時間がかかるのであれば長いままでもいいし、
コメントを書いたほうがわかりやすくなるのであれば書いたほうがいい
4 「理解するまでにかかる時間」は競合する？
高度に最適化されたコードであっても、理解しやすくすることができるはず。
理解しやすいコードは、優れた設計やテストのしやすさにつながることが多い。
