在多年以前，人们注重功能是如何实现的。现如今，随着Web及互联网技术的不断发展，功能仅成了最基本的要求，如何写出漂亮，整洁的代码已成为一个大牛级程序员不可或缺的条件。

一位前端开发工程师便在知乎上提问：“我是一名前端开发工程师，主要编写JavaScript，有两年经验。最近在写一些页面上的模块，发现自己在构思的时候总是很清晰，但是写着写着感觉代码越来越乱，看起来就像一坨屎，而我又有点儿代码洁癖，看着越来越乱的代码就不想进行下去。请问怎么办呢？”并且他还晒了一下自己编写的JavaScript代码：

面对如此乐知好学、积极进取的程序员，我们的网友们也很给力，不仅对他的代码进行了全方位的点评，还提出了一些非常合理的建议，下面就是知呼网上一些网友的精彩回答，让我们一起来看下：

长天之云：

我觉得写好代码和作文章差不多，无外乎：工整、优雅、拒绝重复、惜字如金。下面提供几个小建议：

态度

对代码要有感情，每一行都应该尽心尽力，并且还要有把那些扔垃圾篓的代码再重写两遍的冲动——一旦有了这种冲动之后，什么都挡不住你，连吃喝拉撒时，问题都会浮现到你脑子里，你就会不由自主地解决它们……能对自己的代码提出怀疑本身就是一件了不起的事！加油！

少写代码

提前设计能有助于少写代码，增强全局感。而代码写得少还能防止失控——感觉不对时就应该停下来，腾出时间来思考，为什么会偏离最先的想法。所有符号各就各位。第一眼就是空格太少，下面推荐三个工具给大家：

1. Beautify JavaScript or HTML可以给你的代码格式化，记得用diff工具对照一下，格式化前后的区别；
2. SublimeLinter可以动态地在编写时给出JSHint提示（出错行高亮）；
3. Grunt可以在文件变更时给出SHint检验（声音以及桌面通知）；

一旦把lint校验做为提交代码的必要过程，排版就会有本质的提高。

遵行惯用法

1. 注释符号‘//’后应该空一格；
2. 防止变量提升，应先声明后使用（JSHint会提醒出‘_height’存在变量提升以及定义后未使用的错误）；
3. 不应该使用硬编码，并且重复几次（ID后缀名可以定义到常量里，用大写字母）；
4. 不应该有两个配置属性，含义不明（this.opts和this._options）；
5. 若两次以上引用同一对象的属性，应该定义到局部变量再引用（var options = this._options）；
6. 不应该同时使用两种属性命名风格（colModel和table_body）；
7. 局部变量名应该尽可能短，而方法名应该尽可能完整（不应该同时即有fromatTpl又有parseTemplate）；
8. 局部变量名不需要用下划线开头，仅对象私有属性和私有方法有此必要；
9. 变量名不需要带类型属性（_thdoms叫ths就好）；
10. 使用JavaScript时，for循环基本可以避免（比如jQuery有$.each, $.map，$.filter, $.grep等等高阶函数可用）；
11. jQuery对象名习惯以$开头，以便区分DOM对象；
12. jQuery查询应尽量使用ontext（如 this.$table = $('table', this.$element) ）；
13. jQuery DOM操作和原生DOM操作不应该混用（已经使用jQuery的情况，就应该坚持使用jQuery来操作DOM，避免丑陋的原生操作）；
14. DOM元素构造出来，也不应该再到文档中查询一遍了（图上的构造太复杂，一眼真看不懂）；

代码复查

把程序写正确还只是跨出了第一步。把代码交给你的同事和朋友复查，这是学习经验、共同提高 最快的办法。

大石头Dion：

代码风格及排版

虽然任何一种语言都没有任何约定的风格，但也总有一些不成文且喜闻乐见的习俗。以你的代码为例，给以下几个风格上的建议：

• 每个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对楼主的代码也进行了详细的点评，并且也给出了一些非常有意义的指导：

1. 代码中逻辑没有分块、没有空行、没有注释、看起来很累，建议对代码进行分块，比如将变量集中在头部定义，然后处理一些赋值，最后执行一些其它的函数。具体到这个例子，有很多不恰当的地方，比如可以先var _height；然后在条件分支中进行赋值，比如在一堆赋值语句中间夹杂了一个parseTemplate。
2. “_”用得太多，this._var这个可以理解，因为要区分是否私有变量，但是var _height这个完全没有必要加，加得太多反而看着很累，而且也没有任何区分的意义。
3. 没有将常用的变量缓存，这里最应该缓存的是this._options，要不然看起来很乱，而且缓存起来对性能也是有好处的。
4. 对象的规划（命名）不清晰，比如this._options和this.opts什么关系？我反正是看不明白。
5. 代码风格不统一，比如访问对象，之前都是this._options.height，为什么后面出来一个this._options.data['head']？用this._options.data.head不是更清晰么？
6. 函数内变量名混乱（和第四点很像），比如第二个函数中id和_id什么关系？为什么不用aaaId和bbbId？cre又是什么，难道是createElement缩写？变量尽量起有意义的，可区分的名字。
7. 函数名称表义不明，命名不符合大部分规范约定。第一眼看到_isHaveTable，我第一反应是，这应该是类似return true或者return false之类的吧。结果一看，这么长，难道返回在后面？又往后看了一眼，这根本