・横80列で折り返す。 普段80列で開発してるわけじゃないけど、横に長いコードも見にくいので。 ・1funtionは30行にする。 これも列指定と同じ意味で。 数字自体はそこまで意味がないけど、長いコードはそれ自体問題がある可能性が高い。 ・1ファイルは200～300行 「JSを1ファイルに200行以上書くと人間は死ぬ」と言われてるけど、実際はもうちょっと多くても大丈夫。 ・インデントは8タブ タブを使う理由は「タブはスペースに一括置換できるけど、スペースはタブに一括置換できない」から。 なので、コード中にコードインデント以外でハードタブは記述しない(文字列内に記述する時は¥tで記述する) タブの表示数はエディタ毎の設定次第だけど、インデントの深いコードが書きにくくなるので8タブで書く。 ただし、インデントの文字数に依存するインデントはしない(4タブでも正常なインデントになるように記述する) 8タブ、横80列だとインデントは3～4で折り返すので、それでも大きく崩れないように整形する。 タブインデントに対するスペースインデントの利点として「パッチをやりとりする場合にインデントが崩れる可能性が低い」点があるけど、最近はパッチを送られる場合基本的にバージョン管理システム経由が多いのであまり問題ないと思う。 (この点が問題になる場合、スペースインデントの方がいいかもしれない) これに関しては記述性ではなく可読性の問題なので、エディタが自動変換できるかどうかは問題ではない。 (スペースインデントの表示幅を自由に設定できる閲覧環境が一般的になればどちらでも構わない) ・変数名の長さはスコープの長さに比例させる 変数名はその変数がどの位の範囲から参照されるかによって名前の長さを決める。 変数の参照される範囲が狭いのであれば変数名も短く、範囲が広いのであれば変数名は長くする。 これは基本的にその変数の役割に依存しない。たとえループカウンタであっても広い範囲から参照されるのであれば長い変数名にする。 ただし、これはあくまでも実際広い範囲から参照されるかどうかによって決める。 言語仕様上広い範囲から参照する事が可能でも、実際狭い範囲からしか参照しないのであれば変数名は短くする。 目安としては以下くらい。 1ブロック(5行程度)であれば1ワードの省略形 1funtion(30行程度)であれば1～2ワードの非省略形(2～4ワード程度の省略形も可) 広域変数であれば4～6ワードの非省略形(オブジェクトのプロパティであれば、オブジェクト名もワード数として数える) ・制御構文のブロックを省略しない ifやforなんかの制御構文は、例えreturn;のみの実行であっても基本的にブロックの{}を省略しない。 これはデバッガにかけた場合、ブレークポイントを打ちにくくなるため。 この点が問題ないなら省略してもいいけど、各種ブラウザのデバッガを考慮するとしばらくは省略しない方が無難。 ・ライブラリ等の共通部分には無名関数ではなく、匿名関数を使う 無名関数はvar hoge = funtion () {};のようなもの。 匿名関数はvar hoge = funtion hoge () {};のようなもの。 無名関数を使うとデバッガやプロファイラが正しく名前を出してくれないので。 ただ、dynaTraceは無名関数ソースの位置でプロファイル結果を出してくれるし、デバッグ時もそこまで困る事も多くないので、ある程度共通で使うようなライブラリ部分だけで十分だと思う。 ・条件分岐、変数は極力減らす 条件分岐や変数はバグの元になりやすいので極力減らす。 複数条件を同時に判定している場合、個別に判断して判断条件を減らす。 forは変数や条件分岐を使うのでforEachにする。 値の一致は先にハッシュテーブルを作成してハッシュキーでの一致にする。 if () {/* code */} else {/* code */}ではなく、if () {/* code */ return; } /* code */にする。 method chainにする。 ・method chainは速度に影響しない範囲で使用する 特にjQueryの場合、速度を気にすると実際method chainは多用しなくなる。 method chainは変数、条件分岐を自然に排除できるのでバグを生みにくいけど、デバッグはしにくいのでmethod chainでロジックを書くのは避ける。 method chainをデバッグしやすくする仕組みもあるけど、どのみち多用するとパフォーマンスに影響しやすくなるので、速度を気にして使えばデバッグに困るレベルで使用する事は少ないと思う。