如何编写出优美的JavaScript代码？(转)
在多年以前，人们注重功能是如何实现的。现如今，随着Web及互联网技术的不断发展，功能仅成了最基本的要求，如何写出漂亮，整洁的代码已成为一个大牛级程序员不可或缺的条件。
一位前端开发工程师便在知乎上提问：“我是一名前端开发工程师，主要编写JavaScript，有两年经验。最近在写一些页面上的模块，发现自己在构思的时候总是很清晰，但是写着写着感觉代码越来越乱，看起来就像一坨屎，而我又有点儿代码洁癖，看着越来越乱的代码就不想进行下去。请问怎么办呢？”并且他还晒了一下自己编写的JavaScript代码：
面对如此乐知好学、积极进取的程序员，我们的网友们也很给力，不仅对他的代码进行了全方位的点评，还提出了一些非常合理的建议，下面就是知呼网上一些网友的精彩回答，让我们一起来看下：
长天之云：
我觉得写好代码和作文章差不多，无外乎：工整、优雅、拒绝重复、惜字如金。下面提供几个小建议：
态度
对代码要有感情，每一行都应该尽心尽力，并且还要有把那些扔垃圾篓的代码再重写两遍的冲动——一旦有了这种冲动之后，什么都挡不住你，连吃喝拉撒时，问题都会浮现到你脑子里，你就会不由自主地解决它们……能对自己的代码提出怀疑本身就是一件了不起的事！加油！
少写代码
提前设计能有助于少写代码，增强全局感。而代码写得少还能防止失控——感觉不对时就应该停下来，腾出时间来思考，为什么会偏离最先的想法。所有符号各就各位。第一眼就是空格太少，下面推荐三个工具给大家：
- Beautify JavaScript or HTML可以给你的代码格式化，记得用diff工具对照一下，格式化前后的区别；
- SublimeLinter可以动态地在编写时给出JSHint提示（出错行高亮）；
- Grunt可以在文件变更时给出SHint检验（声音以及桌面通知）；
一旦把lint校验做为提交代码的必要过程，排版就会有本质的提高。
遵行惯用法
- 注释符号‘//’后应该空一格；
- 防止变量提升，应先声明后使用（JSHint会提醒出‘_height’存在变量提升以及定义后未使用的错误）；
- 不应该使用硬编码，并且重复几次（ID后缀名可以定义到常量里，用大写字母）；
- 不应该有两个配置属性，含义不明（this.opts和this._options）；
- 若两次以上引用同一对象的属性，应该定义到局部变量再引用（var options = this._options）；
- 不应该同时使用两种属性命名风格（colModel和table_body）；
- 局部变量名应该尽可能短，而方法名应该尽可能完整（不应该同时即有fromatTpl又有parseTemplate）；
- 局部变量名不需要用下划线开头，仅对象私有属性和私有方法有此必要；
- 变量名不需要带类型属性（_thdoms叫ths就好）；
- 使用JavaScript时，for循环基本可以避免（比如jQuery有$.each, $.map，$.filter, $.grep等等高阶函数可用）；
- jQuery对象名习惯以$开头，以便区分DOM对象；
- jQuery查询应尽量使用ontext（如 this.$table = $('table', this.$element) ）；
- jQuery DOM操作和原生DOM操作不应该混用（已经使用jQuery的情况，就应该坚持使用jQuery来操作DOM，避免丑陋的原生操作）；
- DOM元素构造出来，也不应该再到文档中查询一遍了（图上的构造太复杂，一眼真看不懂）；
代码复查
把程序写正确还只是跨出了第一步。把代码交给你的同事和朋友复查，这是学习经验、共同提高 最快的办法。
代码风格及排版
虽然任何一种语言都没有任何约定的风格，但也总有一些不成文且喜闻乐见的习俗。以你的代码为例，给以下几个风格上的建议：
- 每个function之间多一空行，是的，除去注释外再多一空行；
- 适当加空格，比如if和后面的括号之间的空格、小括号和花括号之间的空格、冒号和function之间的空格等等；
- 风格上保持一致，你的代码里面有的地方+号和运算数之间有空格，有的则没有；
- 少用下划线开头的变量命名；
- 一段代码里，var语句可以合并在一起；
- 暂时不会再修改的function或object，先用编辑器折叠起来，看上去也会整洁很多；
- 黑色背景的Editor风格不错，不过关键字、注释、运算符等颜色上可以再调整，主要是为了防止审美疲劳，换个色调换个心情；
使用成熟的JavaScript库
如果没看错的话，你可能是使用了jQuery吧（至少也有一个类似Sizzle或更简单的解析器，证据在倒数第十行左右）。所以，就尽可能避免使用原生的JavaScript DOM操作。
jQuery的$符号，以CSS Selector风格统一取代了各种getElement(s)ByXxx的接口，并且扩展性非常强，是很多设计模式思想的综合运用。
当然原生DOM也有自己的优势（主要是执行效率），但是大部分时候，在开发效率、代码质量、执行效率的tradeoff中，jQuery还是最佳选择。此外也推荐下JavaScript MVC库、jQuery UI库等等。
代码整理
构思清楚，再写代码，你已经做到了。
但是，谁能保证代码是一成不变、一劳永逸的呢？
所以，「重构」的时候，除非是时间紧迫，永远不要松懈代码质量。
Web前端爱好者TooBug对楼主的代码也进行了详细的点评，并且也给出了一些非常有意义的指导：
- 代码中逻辑没有分块、没有空行、没有注释、看起来很累，建议对代码进行分块，比如将变量集中在头部定义，然后处理一些赋值，最后执行一些其它的函数。具体到这个例子，有很多不恰当的地方，比如可以先var _height；然后在条件分支中进行赋值，比如在一堆赋值语句中间夹杂了一个parseTemplate。
- “_”用得太多，this._var这个可以理解，因为要区分是否私有变量，但是var _height这个完全没有必要加，加得太多反而看着很累，而且也没有任何区分的意义。
- 没有将常用的变量缓存，这里最应该缓存的是this._options，要不然看起来很乱，而且缓存起来对性能也是有好处的。
- 对象的规划（命名）不清晰，比如this._options和this.opts什么关系？我反正是看不明白。
- 代码风格不统一，比如访问对象，之前都是this._options.height，为什么后面出来一个this._options.data['head']？用this._options.data.head不是更清晰么？
- 函数内变量名混乱（和第四点很像），比如第二个函数中id和_id什么关系？为什么不用aaaId和bbbId？cre又是什么，难道是createElement缩写？变量尽量起有意义的，可区分的名字。
- 函数名称表义不明，命名不符合大部分规范约定。第一眼看到_isHaveTable，我第一反应是，这应该是类似return true或者return false之类的吧。结果一看，这么长，难道返回在后面？又往后看了一眼，这根本就没有返回啊！那为什么要用_isHaveTable啊？_is开头的函数明明白白就应该返回一个true或者false啊。
以上是比较精彩的回答。保持适当的空格、风格统一、使用一些约定成俗的命名规则，比如局部变量名应该尽可能短，而方法名应该尽可能完整。