Javascript编码的好习惯（持续更新）
前言：本文主要是总结自己在js开发中的收获，并提炼成一些良好的习惯，希望对以后的工作有警示的作用。同时也会持续更新，补充一些新的内容。
编码前
1.选择一款合适的开发工具。
“工欲善其事必先利其器”，这句话在开发中尤为重要。一些优秀的开发工具可以显著提高开发工作的效率，如Aptana、notepad++等。
目前我在使用的工具：sublime text 2
官方网址：http://www.sublimetext.com/
下载地址：http://www.sublimetext.com/2
使用说明：Sublime Text 2 – 非常强大的跨平台编辑器
一些有用的插件：一些必不可少的Sublime Text 2插件
2.组件开发中的MVC的设计思想。
js中也可以设计出非常漂亮的mvc架构。这是我在近期js开发中体会到的。
一个良好的mvc架构可以让你的js组件在复杂的项目开发中更易整理思路，后期也会变得更易维护。
如果想对js中的MVC有更深入的了解，你可以去体会一下一些优秀框架的设计思想，如backbone.js。
backbone简介：Backbone JS框架指南
这里推荐一本刚刚收到的图书《基于MVC的javascript web富应用开发》，粗略看了下，很不错，很系统，覆盖的知识很全面，强烈推荐！
卓越地址：基于MVC的javascript web富应用开发
编码中
1.变量的命名和文档关键部位的注释。
程序中变量的命名是一门艺术，合理高效的命名方式可以让你的程序具有极高的可读性，同时也为你日后的程序维护提供了非常大的方便。关键逻辑的注释则是为自己的程序做了mark，为自己检查，更是为了让其他人能够轻松迅速的理解你的思路。我往往认为后者是更为重要的。
过去在自己的代码中曾不止一次出现过如data、tempdata、temp，甚至是myData这样笼统而含义模糊的变量名称，直到要检查代码逻辑上的合理性的时候才会体会到这样命名带来的痛苦。而全文没有一次注释，代码几百行,更是让读者痛苦不堪。
一篇很好的介绍变量命名的文章:史上最糟糕的两个变量名
2.尽量减少全局变量。
这样做的原因是，你永远不能保证自己定义的全局变量在应用中一定是唯一的，尤其是在使用其他类库或者他人的文件协同开发的情况下。
所以，尽量减少全局变量的定义，减少产生冲突的概率。
很多时候，我们完全可以通过把这些变量放到特定的命名空间中来使用，从而减少了全局变量的定义。
3.聪明的使用一些技巧。
晚上 看到一篇文章，提到如何快速构建字符串，对我很有启发，现将原文摘抄如下：
要对一个数组或对象做循环操作时，不要老惦记着一表人才的for语句，拿点创意出来嘛！明明就还有很多更快的办法：
1 var arr = ['item 1', 'item 2', 'item 3', ...]; 2 var list = '<ul><li>' + arr.join('</li><li>') + '</li></ul>';
“没那么多繁文缛节来烦你；你就信我一次好了（或者你也可以自己试一试）—— 这真的是迄今能找到的最快办法了！用点土办法，也别管它背后究竟发生了什么抽象的东西，通常土办法都比那些优雅的办法要快捷得多！”– James Padolsey, james.padolsey.com
4.相同的业务逻辑提取成功能函数或者模块。
有时候项目复杂的时候可能会有难于预计的文件数量，我们不可能单纯因为某部分公用性的逻辑简单而放弃提取功能模块。很多时候我们都习惯于对html的header和footer部分进行了文件的封装，而对于其他部分可能还没有形成封装的习惯。这真的不是一个好的习惯。不仅仅是html、js文件，其他各种语言都应该有这样的思想，php，c，java。。。这样在项目规模变的越来越大的时候，你会发现你的维护工作并不会因此而变得越来越复杂。
5.预判可能频繁变化的地方写在一起，封装变化。
这一条建议跟上一条是有区别的。比如一个config文件（即使它可能非常小，可能只有两三条命令），它应该是所有的页面都使用到的，但是根据使用环境的不同随时可能发生变化，这样不如单独提取到外部文件，单独控制config文件来调整整个项目的配置情况。
6.“我们不需要重新发明轮子。”
在设计某些通用性业务逻辑时，最好先去看看有没有“前辈”已经做过这方面的研究。在我们苦苦摸索的时候，可能早已有人提供了比较完善的解决方案。所以，“我们不需要设计汽车上的每个轮子，明白了轮子的设计原理，我们完全可以在已有轮子的基础上做个性化的改进”。编码前，搜索相关的网络资源或是咨询项目组的成员看来是个提高工作效率的有效实践。那些设计好并测试过的设计，往往可以让我们自己少走很多弯路。
编码后
1.编码完成后，提交前先在本地进行测试。
保证代码功能无误后再提交，很多时候本地测试没做好就提交，造成了很多不必要的麻烦。
2.代码测试完毕后，发布前一定要删除源文件中所有的console。
开发中最喜欢的是console.log，但是这在ie下可能会出现怪异现象，提示对象未定义的错误。所以上线提交前要删除所有的console。
3.如果是跟其他人交接项目，除了文档中有清晰明了的注释，请认真写好交接文档，比如readme。
一个比较好的交接文档模板（根据二哥的文档总结而来）应该是这样的：
1》项目的环境支持情况（项目在什么软硬件条件下可以正常运行）。
2》关键性的配置情况（config文件的各个参数的使用说明）。
3》文档目录及相关功能（项目架构及不同模块实现的功能）。
4》目前存在的bug和可能出现的场景。
其实一个交接文档并不需要多么详细，因为它并不是面向一般用户的使用说明，它是为了让其他开发人员能够更迅速的接手你的工作，所以关键性的问题介绍清楚就应该可以了。
简洁明了的说明是一种美德，更应成为一种习惯。
