作为一名开发人员（WEB前端JavaScript开发），不规范的开发不仅使日后代码维护变的困难，同时也不利于团队的合作，通常还会带来代码安全以及执行效率上的问题。本人在开发工作中曾与不按规范来开发的同事合作过，与他合作不能用“愉快”来形容了。现在本人撰写此文的目的除了与大家分享一点点经验外，更多的是希望对未来的合作伙伴能够起到一定的借鉴作用。当然，如果我说的有不科学的地方还希望各路前辈多多指教。下面分条目列出各种规范要求，这些要求都是针对同事编码毛病提出来的，好些行业约定的其它规范可能不会再提及。

　　1、保证代码压缩后不出错

　　对于大型的JavaScript项目，一般会在产品发布时对项目包含的所有JavaScript文件进行压缩处理，比如可以利用Google Closure Compiler Service对代码进行压缩，新版jQuery已改用这一工具对代码进行压缩，这一般会去掉开发时写的注释，除去所有空格和换行，甚至可以把原来较长的变量名替换成短且无意义的变量名，这样做的目的是加快文件的下载速度，同时也减小网站访问带来的额外数据流量，另外在代码保护上也起到了一点点作用，至少压缩后的代码即使被还原还是没那么容易一下读懂的。要想代码能正确通过压缩，一般要求语句都要以分号正常结束，大括号也要严格结束等，具体还要看压缩工具的要求。所以如果一开始没有按标准来做，等压缩出错后再回去找错误那是浪费时间。

　　2、保证代码能通过特定IDE的自动格式化功能

　　一般较为完善的开发工具（比如Aptana Studio）都有代码“自动格式”化功能，这一功能帮助实现统一换行、缩进、空格等代码编排，你可以设置自己喜欢的格式标准，比如左大括号{是否另起一行。达到这个要求的目的在于方便你的开发团队成员拿你代码的一个副本用IDE自动格式化成他喜欢或熟悉的风格进行阅读。你同事需要阅读你的代码，可能是因为你写的是通用方法，他在其它模块开发过程中也要使用到，阅读你的代码能深入了解方法调用和实现的细节，这是简单API文档不能达到的效果。

　　3、使用标准的文档注释

　　这一要求算是基本的，这有利于在方法调用处看到方法的具体传参提示，也可以利用配套文档工具生成html或其它格式的开发文档供其他团队成员阅读，你可以尝试使用jsdoc-toolkit。如果你自动生成的API是出自一个开放平台，像facebook.com应用，那么你的文档是给天下所有开发者看的。另外编写完整注释，也更方便团队成员阅读你的代码，通过你的参数描述，团队成员可以很容易知道你编写的方法传参与实现细节。当然也方便日后代码维护，这样即使再大的项目，过了很长时间后，回去改点东西也不至于自己都忘记了当时自己写的代码是怎么一回事了。