命名
- 意味のある対比を行う
→対比される対象がある場合に、違いがはっきりと分かる名前を付ける。
２つのクラスに ProductInfo、 ProducetData のような名前を付けてはいけない。
２つのメソッドに、 getAccount() と getAccountInfo() のような名前を付けてはいけない。
変数
-
変数の寿命(変数を宣言してから使用するまでの行数)を短くする
→10行程度ならまとめて宣言してもOK -
小さなスコープで変数を定義する
→スコープが大きいほど確認しなければならない範囲が増えてしまう。 -
レキシカルスコープは極力使わない
→できるだけ引数を通して値を受け渡す。コードが追いやすくなる。
関数
-
関数は小さい事が重要
→20行以上の長すぎる関数を作成しない -
関数は1つの機能のみ実装する(責務を限定する)
-
条件分岐はなるべく書かない
-
DRY原則で
→ただし目的の違う関数は共通化しない -
引数が多い場合はオブジェクトにまとめる(3個以上)
-
論理和（||）よりデフォルト引数を使う
-
フラグ引数は使わない
→関数内での条件分岐は極力避ける。true/falseの場合で、それぞれ関数を定義すべき。if文などを排除することにより、関数が小さくでき、デッドロジックもなくなる。 -
副作用を避ける(関数が1つの事を行なう事を保証しつつ、隠れて別の事を行なう事を避ける)
ループ分
- ループの処理は複雑化せずに１つのループに１つの機能として記述する
→ループ処理を分けてもパフォーマンスは気にするほど下がらない。
条件分岐
-
基本的に厳密透過演算子（===）を使う
-
境界条件のカプセル化
→変数で条件をまとめる。長すぎる場合は関数に切り出してもいい。 -
ヨーダ条件式
→条件文（if文など）の中で、変数よりもリテラル値を前に配置する。
if (5 == x) {
// 何らかの処理
}
-
条件分岐・swich分よりも連想配列でまとめられないか検討
-
早期return
-
if文ではなくクラスやコールバック関数の利用を考える
コメント
前提
- コメントが必要になるときはそもそも、処理が大きくなり過ぎている可能性が高い
- コードで解決できる部分はコードで解決する
- コードが見づらいことをコメントで解決することは根本的な解決にはならない
- コメントと処理内容が食い違っていた場合はかえって混乱を招く
良いコメントとは
- 使用上の注意・警告
- パフォーマンスなどに関わるコメント
- 正規表現の意図を表すコメント
- TODO、FIXME、NOTEなどのアノテーションコメント