【Flex】Flexのコーディング規約のお話
こんにちは、橋本です。
今日はFlexのコーディング規約についてお話しようと思います。
「え、Flexにコーディング規約なんてあったの!?」
とお思いの方も多いかと思いますが、実は公式のコーディング規約が存在します。
Flex SDK coding conventions and best practices
日本語訳はこちら
今日はこの中で個人的に気になったところを拾って見ていきたいと思います。
略語
個人的には、obj(object)、arr(array)、str(string)なんかも標準に入れても良い気がするのですが。
プロパティ名(変数およびgetter/setter)
for文に関しては、特に異論はないのですが、for-in文の規約には個人的に納得出来ないというか、微妙な気がします。
pってわかりにくいですよね?
for-in文の中でさらにfor-in文を使うときにはどうするんでしょうか?pをプロパティの頭文字と言うのであれば、qだとおかしいですよね?だとすると、p2?
微妙ですね。。。
ストレージ変数名
これも、好き嫌いがあると思います。個人的には、内部プロパティについては、全て_hogehogeといった感じで、アンダーバーからスタートする変数名に統一するのが、意外と分かりやすくていいんじゃないかな、と。
イベントハンドラ名
イベントハンドラについては、onを接頭詞として付ける派(onMouseDown、など)の方もいらっしゃるかと思いますが、FlashBuilder4から追加された、イベントハンドラを自動で作成してくれる機能では、上記の規約に従ってメソッドが作成されるので、こちらに移行した方がいろいろと楽かもしれません。
引数名
個人的には、setterの引数には、setする引数名を使いたくなるんですが。。
どっちがわかりやすいんでしょうか。
型宣言
これは、めんどくさいんですが、慣れるとコードが読みやすくていいかもしれません。
こんな感じです。
また、この規約はFlash10以降使えるようになった、Vectorクラスの記述に似せたものなのかもしれません。
Vectorクラスは配列みたいなものなのですが、中に格納するデータの型を指定する必要があります。
リテラル
ArrayとObjectは基本かと思いますが、Stringが気持ち悪いですね。わざわざエスケープするくらいなら、シングルクォート使う方がわかりやすいと思うんですけどね。。
ifステートメント
1番はまぁいいのですが、2番はブロックにしたいですよね。なんとなく気持ち悪い。。。
forステートメント
なんで、ifと逆なんだ…。
switchステートメント
これは慣れると、非常に見やすいです。
PHPを書いてるときにも、switch文の書き方に違和感を感じていたので、この書き方は目から鱗でした。
ちなみに、PHPでもこの書き方、できます。
ローカル変数
AS3はブロック内のみが有効範囲のローカル変数に対応しておらず、変数名の重複でコンパイルエラーが出るときが多々あるので、個人的には、最初にまとめて宣言しちゃいたいです。
まぁ、変数名にもっと気を使ってコード書けって話になるのかもしれませんが。
記述書式
一行あたり80文字は少なくないですか。
下手したら、メソッドの宣言だけで80文字こえちゃいますよ?
メリットは確かにあるのかもしれませんが、普段コードを書く分には80文字だと少し物足りないですよね。
インデント
PHPを書くときは、半角2文字派だったんですが、慣れると4文字の方が見やすいです。
その他にもいろいろとあるのですが、個人的に気になったのはこの辺でしょうか。
コーディングスタイルは人それぞれだと思いますので、そんなに気にすることもないのかもしれませんが、
時間があれば一度目を通してみると、いろいろと発見があって面白いかもしれません。
今日は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:
- 文字列の区切りとしては、たとえその文字列にクオーテーションマークが文字として含まれている場合でも、アポストロフィ(1重引用符)ではなくクオーテーションマーク(2重引用符)を使用します。
- "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番はまぁいいのですが、2番はブロックにしたいですよね。なんとなく気持ち悪い。。。
forステートメント
- たとえステートメントが1つしかない場合でも、{{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字で折り返します。
これにより以下のメリットを享受できます。 - デベロッパーが小さな画面を使用している場合でも、長い行を読む際に水平にスクロールする必要がありません。
- 比較ユーティリティを使用する際、ファイルの2つのバージョンを並べて表示できます。
- プロジェクタを使用してグループにプレゼンする際、スクロールではなくフォントサイズを大きくすることで対応できます。
- 途切れや無駄な改行なく、ソースコードを印刷できます。
一行あたり80文字は少なくないですか。
下手したら、メソッドの宣言だけで80文字こえちゃいますよ?
メリットは確かにあるのかもしれませんが、普段コードを書く分には80文字だと少し物足りないですよね。
インデント
- 半角スペース4文字のインデントを使用します。
PHPを書くときは、半角2文字派だったんですが、慣れると4文字の方が見やすいです。
その他にもいろいろとあるのですが、個人的に気になったのはこの辺でしょうか。
コーディングスタイルは人それぞれだと思いますので、そんなに気にすることもないのかもしれませんが、
時間があれば一度目を通してみると、いろいろと発見があって面白いかもしれません。
コメントフォーム
トラックバック
最近の記事
- もうすぐ健康診断があるんだ・・・ [2010年09月02日 : 阿部恵]
- Photoshopで壁紙を作りながら、基本的な使い方を覚える [2010年09月01日 : 鴨田健次]
- はじめての共同作業 Canvas編 (node.js + websocket) [2010年09月01日 : 中川善樹]
- 「PHP×Flex(後編)」PHPテクニカルセミナー(無料)第4弾の募集を開始しました!! [2010年08月26日 : 和田記光]
- 【HTML5】Canvasでお絵かきしてみた(前編) [2010年08月25日 : 橋本章史]
- MacにgroongaのMySQL用ストレージエンジン [2010年08月23日 : 笹亀弘]
- Appleのサイトで見たiPhone4をFireworksで描いてみました-1/2 [2010年08月19日 : 和田記光]
- iPad版の会社紹介を作ってみました [2010年08月19日 : 小林有佳]
- iPhoneアプリ開発開始時に気をつけるべきファイルの取り扱い (2) [2010年08月19日 : 亀本大地]
- symfonyセミナー動画無料公開! [2010年08月13日 : 岡本雄樹]



最近のコメント