こんにちは、橋本です。
今日はFlexのコーディング規約についてお話しようと思います。
「え、Flexにコーディング規約なんてあったの！？」
とお思いの方も多いかと思いますが、実は公式のコーディング規約が存在します。
Flex SDK coding conventions and best practices
今日はこの中で個人的に気になったところを拾って見ていきたいと思います。
略語
原則は、略語を使用しないということになっていますが、一部標準化されている略語があります。
acc: accessibility（アクセシビリティ）。使用例: ButtonAccImpl
auto: automatic（自動）。使用例: autoLayout
eval: evaluate（評価）。使用例: EvalBindingResponder
impl: implementation（実装）。使用例: ButtonAccImpl
info: information（情報）。使用例: GridRowInfo
num: number（数値）。使用例: numChildren
min: minimum（最小）。使用例: minWidth
max: maximum（最大）。使用例: maxHeight
nav: navigation（ナビゲーション）。使用例: NavBar
regexp: regular expression（正規表現）。使用例: RegExpValidator
util: utility（ユーティリティ）。使用例: StringUtil
個人的には、obj(object)、arr(array)、str(string)なんかも標準に入れても良い気がするのですが。
プロパティ名（変数およびgetter/setter）
小文字で綴りを開始し、以後の連語をキャメルケース方式で記述します。例: i、width、numChildren。
ループのインデックスにはi、上限値にはnをそれぞれ使用します。 内部ループのインデックスにはj、上限値にはmをそれぞれ使用します。
for (var i:int = 0; i < n; i++)
{
for (var j:int = 0; j < m; j++)
{
...
}
}
for-inループの変数には、p（プロパティの頭文字）を使用します。
for (var p:String in o)
{
...
}
for文に関しては、特に異論はないのですが、for-in文の規約には個人的に納得出来ないというか、微妙な気がします。
pってわかりにくいですよね？
for-in文の中でさらにfor-in文を使うときにはどうするんでしょうか？pをプロパティの頭文字と言うのであれば、qだとおかしいですよね？だとすると、p2？
微妙ですね。。。
ストレージ変数名
getter/setterのfooのストレージ変数には、_fooという名前を付けます。
これも、好き嫌いがあると思います。個人的には、内部プロパティについては、全て_hogehogeといった感じで、アンダーバーからスタートする変数名に統一するのが、意外と分かりやすくていいんじゃないかな、と。
イベントハンドラ名
イベントハンドラには、イベントの種類を示す語句に「Handler」を結合した名前を付けます。例: mouseDownHandler()。
仮にハンドラが、サブコンポーネント（this}}以外のものなど）によってディスパッチされるイベント用のものである場合は、ハンドラ名の前にサブコンポーネント名を付け、これらをアンダースコアで結合します。例: textInput_focusInHandler()。
イベントハンドラについては、onを接頭詞として付ける派(onMouseDown、など)の方もいらっしゃるかと思いますが、FlashBuilder4から追加された、イベントハンドラを自動で作成してくれる機能では、上記の規約に従ってメソッドが作成されるので、こちらに移行した方がいろいろと楽かもしれません。
引数名
各setterの引数には、valueを使用します。
public function set label(value:String):void
各イベントハンドラの引数には、（e、evt、eventObjではなく）eventを使用します。
protected function mouseDownHandler(event:Event):void
個人的には、setterの引数には、setする引数名を使いたくなるんですが。。
private var _hoge:String;
public function set hoge(hoge:String):void
{
_hoge = hoge;
}
どっちがわかりやすいんでしょうか。
型宣言
すべての定数、変数、関数引数、関数の戻り値に対して、型宣言を記述します。
Arrayデータ型を宣言する場合は、/* of ElementType */の体裁のコメントをArray直後に記述し、配列要素の型を示すようにします。 将来バージョンの言語では、型付けされた配列が含まれる見込みです。
これは、めんどくさいんですが、慣れるとコードが読みやすくていいかもしれません。
こんな感じです。
var arr:Array /* of String */ = [];
また、この規約はFlash10以降使えるようになった、Vectorクラスの記述に似せたものなのかもしれません。
Vectorクラスは配列みたいなものなのですが、中に格納するデータの型を指定する必要があります。
private var vector:Vector.<String>;
リテラル
String:
文字列の区切りとしては、たとえその文字列にクオーテーションマークが文字として含まれている場合でも、アポストロフィ（１重引用符）ではなくクオーテーションマーク（２重引用符）を使用します。
"What's up, \"Big Boy\"?";
Array:
new Array()ではなく、配列リテラルを使用する。
var arr:Array = [];
Object:
new Object()ではなく、Objectリテラルを使用する。
var obj:Object= {};
ArrayとObjectは基本かと思いますが、Stringが気持ち悪いですね。わざわざエスケープするくらいなら、シングルクォート使う方がわかりやすいと思うんですけどね。。
ifステートメント
if/elseステートメントの分岐後条件に単一のステートメントのみが含まれる場合は、これらをブロックにすることを避けます。
1.
if (flag)
doThing1();
2.
if (flag)
doThing1();
else
doThing2():
1番はまぁいいのですが、２番はブロックにしたいですよね。なんとなく気持ち悪い。。。
forステートメント
たとえステートメントが１つしかない場合でも、{{for}}ループの命令部分はブロックで記述します。
for (var i:int = 0; i < 3; i++)
{
doSomething(i);
}
なんで、ifと逆なんだ…。
switchステートメント
各case句の内容、およびdefault句の内容はブロックで記述します。breakステートメントおよびreturnステートメントは、ブロックの後ではなくブロック内に記述します。 returnがある場合は、returnをbreakの後に配置しないようにします。 default句はcase句同様に扱うようにし、breakやreturnを記述してswitchの最後まで処理が達するのを防ぐようにします。
switch (n)
{
case 0:
{
foo();
break;
}
case 1:
{
bar();
return;
}
case 2:
{
baz();
return;
}
default:
{
blech();
break;
}
}
これは慣れると、非常に見やすいです。
PHPを書いてるときにも、switch文の書き方に違和感を感じていたので、この書き方は目から鱗でした。
ちなみに、PHPでもこの書き方、できます。
ローカル変数
ローカル変数は、その変数が初めて使用される時点、または使用される直前に宣言するようにします。 すべての宣言を関数の最初の部分に記述することは避けます。
正しい記述例
private function f(i:int, j:int):int
{
var a:int = g(i - 1) + g(i + 1);
var b:int = g(a - 1) + g(a + 1);
var c:int = g(b - 1) + g(b + 1);
return (a * b * c) / (a + b + c);
}
誤った記述例
private function f(i:int, j:int):int
{
var a:int;
var b:int;
var c:int;
a = g(i - 1) + g(i + 1);
b = g(a - 1) + g(a + 1);
c = g(b - 1) + g(b + 1);
return (a * b * c) / (a + b + c);
}
AS3はブロック内のみが有効範囲のローカル変数に対応しておらず、変数名の重複でコンパイルエラーが出るときが多々あるので、個人的には、最初にまとめて宣言しちゃいたいです。
まぁ、変数名にもっと気を使ってコード書けって話になるのかもしれませんが。
記述書式
コードは1行あたり半角文字80字で折り返します。 これにより以下のメリットを享受できます。
デベロッパーが小さな画面を使用している場合でも、長い行を読む際に水平にスクロールする必要がありません。
比較ユーティリティを使用する際、ファイルの２つのバージョンを並べて表示できます。
プロジェクタを使用してグループにプレゼンする際、スクロールではなくフォントサイズを大きくすることで対応できます。
途切れや無駄な改行なく、ソースコードを印刷できます。
一行あたり80文字は少なくないですか。
下手したら、メソッドの宣言だけで80文字こえちゃいますよ？
メリットは確かにあるのかもしれませんが、普段コードを書く分には80文字だと少し物足りないですよね。
インデント
半角スペース４文字のインデントを使用します。
PHPを書くときは、半角2文字派だったんですが、慣れると4文字の方が見やすいです。
その他にもいろいろとあるのですが、個人的に気になったのはこの辺でしょうか。
コーディングスタイルは人それぞれだと思いますので、そんなに気にすることもないのかもしれませんが、
時間があれば一度目を通してみると、いろいろと発見があって面白いかもしれません。