去年の末に「JavaScriptのコーディングスタイル」の記事を書きました(http://dev.ariel-networks.com/Members/inoue/javascript-style)。

と言っても、prototype.jsのスタイルに準拠、しか決めていないので、結構、あうんの呼吸でやっています。諸般の事情により、もう少し精緻に決めることを考えています。

• http://docs.jquery.com/UI_Developer_Guide

jqueryのコーディングスタイルです。あまり強い制約をかけていません。(関数やクラスの説明の)JavaDocコメントを書かずにwikiに書け、という主張には反対です。ぼくは、ソースコードは、自己記述的、自己完結的なのが理想だと思っています。(必要な)文書は、可能な限りソースコードの近くに置くべし、という考えです。 ついでに、インデントにスペース文字ではなくタブ文字を使え、というスタイルも趣味に合いません。

• http://dojotoolkit.org/developer/StyleGuide

Javaの標準スタイルを参考にしたとあります。冒頭の「Any violation to this guide is allowed if it enhances readability」は良いです。コーディングスタイルを決めるのは、可読性を上げるための手段であって目的ではないからです。包括的で、かつ主張も妥当で、好意的に読んでいましたが、Layoutの部分から趣味に合わなくなりました。while、if、forなどの後ろにスペース文字が無いスタイルは違和感があります。単に慣れの問題であることは認識していますが、Javaの標準スタイルを参考にした、と言いながら、なぜこんなところで自己主張をするのか理解できません。

それからこの辺、

function(/*String*/ foo, /*int*/ bar)...

気持ちは痛いほど分かるのですが、いかんせん見た目が悪いです。このコメントの修正洩れが何のチェックもかからない点も怖いです。

prototype.js的なクラス定義で、個人的に最も気持ち悪いのが、publicなメソッドとprivate(internal)なメソッドの区別が無い点です。ぼくは偏執狂的スコープ限定主義者なので、外部から呼んで欲しくないメソッドが無造作に置かれているのを見ると、不安な気分になって落ち着きません。dojoでは命名規約で逃げています(privateはアンダースコアで始める)。これでも、無いよりは、だいぶ気分が落ち着きます。

• http://c2.com/cgi/wiki?JavaScriptCodingStandard

何か主張が書いてあると、反対意見も一緒に書かれるという、JavaScriptのコーディング規約のカオスを象徴するページです。

結論

• インデント幅、カッコの位置、スペース文字の有無などはprototype.js準拠
• 一部を除いてdojotoolkitのコーディングスタイルがまあまあ良いので従う