如何编写出优美的JavaScript代码？

楼主^#

更多发布于：2012-12-11 08:40

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

喜欢0 评分0

举报回复

发帖回复

« 返回列表

您需要登录后才可以回帖，登录或者注册

返回顶部

如何编写出优美的JavaScript代码？

最新喜欢：