編程並不是一個人的戰鬥。既然如此，就必須擁有一套規範，用於統一各個部件的行爲。而最初的問題，則是代碼規範。
這僅僅是一個規範而已。就意義來講，它統一的僅僅是着裝，只是讓大家覺得，編寫出的代碼是一個整體，而不是東拼西湊的異形怪物。但同樣的，它也是最容易做到的。雖然各個團隊都有自己的特殊情況，或者是老資格成員的阻礙，或者是爲了避免潛在的爭端。確實，編碼規範是一個非核心部分，並沒有重要到需要在行業內形成標準，只要在一個團隊內能夠統一，那就完事大吉了。然而，這並不能成爲妨礙討論它的理由。
首先，要向大家推薦一個老物：
http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions
以下是翻譯：
http://www.5uflash.com/yejiezatan/ziyuanfenxiang/3276.html
作爲一個正式項目，當然會制定一個項目本身使用的代碼規範。這並不是Adobe的官方規範，只是FLEX framework自己使用的規範而已。我在這拿出來也只是覺得它設計的不錯，很符合Action Script 3.0的特點，在保障代碼可讀性的同時考慮了不同寫法的性能差異。在自己設計代碼規範的時候，可以作爲很好的參考。而下面就是對裏面一些重點條目的分析。
當然，作爲我個人而言，以我目前所知的知識爲基礎，我覺得它很好以至於我不需要做任何修正。
關於大括號左對齊
Do this:
function f():void
{
var n:int = numChildren;
for (var i:int = 0; i < n; i++)
{
if ()
{
x = horizontalGap * i;
y = verticalGap * i;
}
}
}
Not this:
function f():void {
var n:int = numChildren;
for (var i:int = 0; i < n; i++) {
if () {
x = horizontalGap * i;
y = verticalGap * i;
}
}
}
左大括號不左對齊而是放在上一行代碼的最後，這是一個歷史原因，最初的C確實是這樣做的。然而，那已經是老掉牙的時代了。目前不管是Java,.NET，C++的IDE默認生成代碼以及自動代碼格式都是默認按括號左對齊來處理，甚至連FLASH CS5也都是如此。
這兩種方法的差異是明顯的。第二種作法雖然看起來省了一行，但是左括號由於放在行末，實際上視覺上跟沒有一樣，如果沒有縮進就幾乎無法分辨出代碼結構。更何況，if表達式往往會很長，就算可以斷行最後一行也可能很長，這使得左括號更加難以分辨。實際上，用第二種方式寫代碼的人一定遇到過因爲括號太多縮進錯誤導致無法使括號配套的窘境。而第一種寫法的，因爲括號都在最左邊而且佔用一個空行，幾乎不可能遇到這種情況。
代碼規範的標準是易讀性。雖然兩種方式都可以進行閱讀，但是顯然第一種方式能夠讓人在更短的時間內看清代碼的層次結構。而增加代碼行數這個缺陷，不值一提。
關於私有屬性前置下劃線
這篇規範裏完全沒提前置下劃線什麼事……而沒有規範，這本身就是規範。
前置下劃線這東西在AS領域，應該是來源於一個天殺的代碼規範，很多人都看過它，但目前我怎麼找不到它的網上副本了。那個規範裏要求“所有的”私有屬性都前置下劃線，以便和公共屬性區分。至今，還是有不少人在延續着這個習慣。
私有屬性的目的是封裝，而這是另外一個話題。關鍵在於，我們在編寫一個類的時候，是否需要一直強調自己一個屬性是否是私有屬性？一個私有屬性對於外人而言，是可不見的，能看到這個屬性的只有類的開發者自己，而開發者在這個類裏，所有的屬性都是可以自由使用的，私有屬性和公共屬性並沒有什麼區別。
而且，在開發過程中，乃至後續開發中，一個屬性是否是私有是不確定的。公共變量有可能會被隱藏，私有也可能會被改爲保護。寫法的不同會使得這種修改變得有些麻煩。
當然，更重要的是前置下劃線會影響代碼的可讀性，請看下面的代碼：
this._d[_i]=(_m1.x-_x)–(_m2.y-_y);
雖然在現實中你會在運算符號前後加上空格，但這依然會很古怪。前置下劃線，會讓代碼顯得很“髒”，使得他前面的符號難以辨識。就算它確實有那麼點意義，也不值得。
this.d[i]=(m1.x- x)–(m2.y- y);
老老實實這樣寫吧。私有不私有，根本沒那麼重要。
唯一需要前置下劃線的地方，就是setter/getter，因爲要確保不重名。當然，某些你特別想強調是私有的屬性，可以前置下劃線，但絕不能多。
雜項
官方組織的規範與一般的規範的不同之處，不僅僅是開發人員的經驗豐富，還在於他們能夠得到Flash Player開發人員的支持，因此能夠知道一些我們難以瞭解到的事情，諸如：
n var arr:Array = [] 比 var arr:Array = new Array()快3倍。
n var obj:Object = {} 比 var obj:Object = new Object()快3倍。
n 諸如要求var arr:Array = [];而不是
var arr:Array;
arr = [];
因爲後者實際上是先設置arr = null，然後才設置arr = [];
n 自然，像if (a == true)換成if (a)這種很明顯的地方，編譯器也確實沒有做優化來抹消這個差異，前者會比後者多出一條代碼。
對於一些容易被忽略而非常嚴重的問題，這套規範也表示了重視，諸如以if (s != null && s != "")代替if (s)，因爲在一個字符串s爲””時候，if (s) 是不會執行後面的代碼的。這個事實實際上很多人都不知道，而後果可能非常嚴重。
寫在最後
這套規範很多細節對於改善可讀性幫助都很大，但我要一條一條敘述下去就是×××了，請務必查看原文。本文只是藉此駁斥一些“被普遍應用卻不利於可讀性”的僞標準，雖說作爲團隊成員應該遵守團隊訂立的代碼規範，但是被強制使用一些“影響效率”的規範始終還是比較痛苦的。
代碼規範雖然是不怎麼重要的東西，卻是一切的起始。如果連這個都無法做出正確的處理的話，那麼後面更麻煩的問題實際上也好不到哪裏去。諸如框架的使用，協作模式等等，這些比起代碼規範爭議更多，而且確實可能導致很嚴重的問題。
雖然只是着裝，但畢竟也是件事兒，對吧。