リーダブルコード 1

• コードは理解しやすくあるべき
• 優れているコードとは、動作の違いよりも経験に紐付いたものであることのほうが多い
• 簡潔であることと、安心であること、わかりやすいことは違う
• コードは他人がよめるようにすることが大事。
• たとえ、それを自分しか使わないとしても、未来の自分はほぼ他人と同じ。
• コードが短いことは必ずしもわかりやすいことと直結しない。コメントも同じ
• 理解しやすいコードは、効率化されたコードや設計をうまくする、テストがしやすいなどほかの目的と競合しにくい。
• コードの改善には表面上と表面下の二種類があるが、表面上の方が手間もかからず、効果が大きい。
• 名前に情報をつめることは大事。
• たとえば、tmpなどの汎用的な名前は目的が曖昧でわかりにくい
• 明確な単語を選ぶことが大事。getではなくfetchであるとか。
• 汎用的な名前もなるべく避ける。tmpも本当に一時的なら問題ないが、往々にしてそうでないところでつかわれがちである。
• イテレータでよくつかわれるiもci(characterのc)にするなどで、なんのiなのか明確にするのが大事。
• 抽象的な名前を避ける。具体的な名前、メソッド名であればより何ができるか具体的に表している単語を使用すべき。
• 使っている言葉から意味が明確であるべき
• 名前に情報を追加する。16進数のidであればhex_idにするなど。
• 値の単位を追加するのも有用。startではなくstart_msにすることで、秒とミリ秒の扱いの違いによるバグが起こりにくくなる。
• 長い名前は決して良くない。しかし、そのスコープが大きのであれば長い名前の方が全体としてコストが低くなる。
• 逆に言うと、スコープが小さいのであれば短い変数名でも問題ない。
• 頭文字の省略形も有用だが、それが共通認識としてもたれているものでなければならない。
• 明確さを変えない不要な単語はすてるべき。
• コード規約で定義されたコードのフォーマットに意味を込める