编程并不是一个人的战斗。既然如此，就必须拥有一套规范，用于统一各个部件的行为。而最初的问题，则是代码规范。
这仅仅是一个规范而已。就意义来讲，它统一的仅仅是着装，只是让大家觉得，编写出的代码是一个整体，而不是东拼西凑的异形怪物。但同样的，它也是最容易做到的。虽然各个团队都有自己的特殊情况，或者是老资格成员的阻碍，或者是为了避免潜在的争端。确实，编码规范是一个非核心部分，并没有重要到需要在行业内形成标准，只要在一个团队内能够统一，那就完事大吉了。然而，这并不能成为妨碍讨论它的理由。
首先，要向大家推荐一个老物：
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) 是不会执行后面的代码的。这个事实实际上很多人都不知道，而后果可能非常严重。
写在最后
这套规范很多细节对于改善可读性帮助都很大，但我要一条一条叙述下去就是×××了，请务必查看原文。本文只是借此驳斥一些“被普遍应用却不利于可读性”的伪标准，虽说作为团队成员应该遵守团队订立的代码规范，但是被强制使用一些“影响效率”的规范始终还是比较痛苦的。
代码规范虽然是不怎么重要的东西，却是一切的起始。如果连这个都无法做出正确的处理的话，那么后面更麻烦的问题实际上也好不到哪里去。诸如框架的使用，协作模式等等，这些比起代码规范争议更多，而且确实可能导致很严重的问题。
虽然只是着装，但毕竟也是件事儿，对吧。