JavaScript 常用的开发规范

JavaScript 常用的开发规范

JavaScript 常用的开发规范

1、JavaScript 文件引用

 

JavaScript 程序应该尽量放在 .js 的文件中，需要调用的时候在 HTML 中以 <script src="filename。js"> 的形式包含进来。JavaScript 代码若不是该 HTML 文件所专用的，则应尽量避免在 HTML 文件中直接编写 JavaScript 代码。因为这样会大大增加 HTML 文件的大小，无益于代码的压缩和缓存的使用。

另外，<script src="filename。js"> 标签应尽量放在文件的后面。这样会降低因加载 JavaScript 代码而影响页面中其它组件的加载时间。

 

2、行长度

每行代码应小于 80 个字符。如果代码较长，应尽量选择换行，下一行代码应缩进 8 个空格。这样可以使代码排版整齐，减轻阅读代码的疲劳感。换行缩进 8 个空格可以和代码段的缩进 4 个空格区分开，以增强代码的可阅读性。

 

3、行结束

JavaScript 语句应该以分号结束。但大多数浏览器允许不写分号，只要在本应是分号的地方有一个换行符就行。但是如果代码行较长需要换行的时候，有哪些注意事项呢？换行应选择在操作符和标点符号之后，最好是在逗号','之后，而不要在变量名、字符串、数字、或')' ']' '++' '--'等符号之后换行。

这样可以有效的防止拷贝、粘贴而引起的错误，并可有效地增强代码的可阅读性。请见清单 1，代码的输出符合我们的期望。但就写法而言，对 valueB 的赋值语句是在变量 valueA 之后进行的换行，这很容易被误解为 valueB=ValueA，给阅读造成障碍。而对 valueC 的复制语句是在'+'之后进行的换行，就容易理解的多。这也是本文所提倡的换行方式。

 

4、缩进

关于缩进的问题，不只是 JavaScript，几乎所有的语言编写的时候，都会提及缩进的问题。缩进几乎是代码编写规范的第一课，是代码可阅读性判断的直接因素。

代码缩进的好处是不言而喻的，但是对于如何缩进，则没有标准而言。最受欢迎的是方便使用 TAB 键缩进，也有些喜欢用 2 个、4 个、8 个空格进行缩进。这样缩进风格不一，也同样给代码的阅读带来障碍。

本文提倡用 4 个空格来进行缩进，并在同一产品中采用同一种缩进标准。不支持用 TAB 键进行缩进。这是因为直到现在还没有统一的标准来定义 TAB 键所代替的空白大小，有些编辑器解析为 4 个空格大小，有些则解析为 8 个。因而用不同的编辑器查看代码，可能造成格式混乱。当然 TAB 简单易用，为解决这个问题，建议在设置开发环境时，将编辑器里的 TAB 快捷键重新设置为 4 个空格。据了解 Eclipse, Vi, Nodepad++，Editplus, UltraEdit 等流行的编辑器，均提供了此功能。

 

5、变量的声明

尽管 JavaScript 语言并不要求在变量使用前先对变量进行声明。但我们还是应该养成这个好习惯。这样可以比较容易的检测出那些未经声明的变量，避免其变为隐藏的全局变量，造成隐患。

在函数的开始应先用 var 关键字声明函数中要使用的局部变量，注释变量的功能及代表的含义，且应以字母顺序排序。每个变量单独占一行，以便添加注释。这是因为 JavaScript 中只有函数的 {} 表明作用域，用 var 关键字声明的局部变量只在函数内有效，而未经 var 声明的变量则被视为全局变量

 

6、语句

对于简单语句而言，需要提及的仍然是分号必要性，同时，一行最多有一个语句。如果一个赋值语句是用函数和对象来赋值，可能需要跨多行，一定切记要在赋值语句末加上分号。

这是因为 JavaScript 中，所有表达式都可以当语句，遇换行符时会解析为表达式的结束，此时不规范的换行和分号的丢失，可能引入新的错误。

对于复合语句，if, for, while, do, switch, try … catch 等代码体，函数定义的函数体，对象的定义等都需要放在花括号'{}'里面。

• '{' 应在行末，标志代码块的开始。
• '}' 应在一行开头，标志代码块的结束，同时需要和'{'所在行的开始对齐，以表明一个完整的复合语句段。这样可以极大地提高代码的可阅读性，控制逻辑能清晰地表现出来。
• 被包含的代码段应该再缩进 4 个空格。
• 即使被包含的代码段只有一句，也应该用花括号'{}'包含。尽管不用花括号代码也不会错，但如若需要增加语句的话，则较容易因花括号遗漏而引起的编译错误或逻辑错误。

return语句在使用时也需慎重，如果用表达式的执行作为返回值，请把表达式和 return 放在同一行中，以免换行符被误解析为语句的结束而引起返回错误。return 关键字后若没有返回表达式，则返回 undefined。构造器的默认返回值为 this。

 

7、空白符

适当的空白行可以大大提高代码的可阅读性，可以使代码逻辑更清晰易懂。同时，在表达式中适当的留空白，也会给代码的阅读带来方便。

关键字的后面如有括号，则最好在关键字和左括号'('之间留空白，如 for, if, while 等。而函数名和括号之间则不宜留空白，但若是匿名函数，则必须在 function 和左括号'('之间留空白，否则，编辑器会误认为函数名为 function。

在表达式中，二元运算符 ( 除左括号'('，左方括号'['，作用域点'.') 和两个操作数之间最好留空白。一元运算符（若不是词 typeof 等）和其操作数之间不宜留空白。

逗号','的后面需要留空白，以显示明确的参数间隔，变量间隔等。

分号';'之后通常表明表达语句的结束，而应空行。在 for 的条件语句中，分号之后则应该留空白。

 

8、{ } 和 [ ]

在 JavaScript 中，如需定义空对象和空数组，通常很自然地想到用 new Object() 和 new Array() 的方法。其实花括号'{}'和方括号'[]'可以直接用来定义一个空对象和一个空数组。这种书写方法可以使代码看起来简单易懂。

 

9、== 和 ===

判断"逻辑等"在代码里太平常的不过事情了，但 JavaScript 与其他熟知的编程语言不同的是，除了可以使用两个等号'=='来作判断以为，还可以使用三个等号'==='来进行逻辑等判断。两者的不同是'=='作逻辑等判断时，会先进行类型转换后再进行比较。'==='则不会。因而，'=='进行的判断结果可能产生偏差。'!='与'!=='的区别亦是如此。本文提倡尽量使用'==='来进行逻辑等的判断，用'!=='进行逻辑不等的判断。

 

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

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

 

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

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

 

12、使用标准的文档注释

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

代码中的注释很重要，自然也是毋庸置疑的。通常我们会强调代码中注释数量的多少，而轻视了对注释质量的提高。编码是及时添加注释，会给后续代码的维护人员带来很大的便利。但是如果注释不注意更新，或者由于拷贝、粘贴引起的错误的注释，则会误导阅读人员，反而给阅读带来障碍。

除了注释要及时更新外，我们还应对注释的内容要特别关注。注释要尽量简单、清晰明了，避免使用含混晦涩的语言，同时着重 注释的意义，对不太直观的部分进行注解。

 

13、使用规范有意义的变量名

使用规范有意义的变量名可以提高代码的可读性，作为大项目开发成员，自己写的代码不仅仅要让别人容易看懂。开发大项目，其实每个人写的代码量可能都比较大，规范命名，日后自己看回自己的代码也显的清晰易懂，比如日后系统升级或新增功能，修改起代码来也轻松多了。如果到头发现自己当初写的代码现在看不太懂了，那还真是天大的笑话了。

当然，使用有意义的变量名也尽量使用标准的命名，比如像这里：var me = this也许没有var self = this好，因为self是Python中的关键字，在Python中self就是通常语言this的用法。再看下面一个例子，加s显然比没有加来的科学些，这样可以知道这个变量名存的是复数，可能是数组等：

变量名包括全局变量，局部变量，类变量，函数参数等等，他们都属于这一类。

基本规范

变量命名都以类型前缀+有意义的单词组成，单词首字母都需要大写。例如：sUserName，nCount。

前缀规范

每个局部变量都需要有一个类型前缀，按照类型可以分为：

　　s：表示字符串。例如：sName，sHtml;

　　n：表示数字。例如：nPage，nTotal;

　　b：表示逻辑。例如：bChecked，bHasLogin;

　　a：表示数组。例如：aList，aGroup;

　　r：表示正则表达式。例如：rDomain，rEmail;

　　f：表示函数。例如：fGetHtml，fInit;

　　o：表示以上未涉及到的其他对象，例如：oButton，oDate;

例外情况：

　　1：作用域不大临时变量可以简写，比如：str，num，bol，obj，fun，arr。

　　2：循环变量可以简写，比如：i，j，k等。

　　为什么需要这样强制定义变量前缀?正式因为javascript是弱语言造成的。在定义大量变量的时候，我们需要很明确的知道当前变量是什么属性，如果只通过普通单词，是很难区分的。

 

14、不使用生偏语法

JavaScript作为一门动态脚本语言，灵活性既是优点也是缺点，众所周知，动态语言不同层次开发人员对实现同样一个功能写出来的代码在规范或语法上会存在较大的差别。不管怎么样，规范编码少搞怪，不把简单问题复杂化，不违反代码易读性原则才是大家应该做的。

 

15、明确定义函数固定数量的参数

固定数量参数的函数内部不使用arguments去获取参数，因为这样，你定义的方法如果包含较多的脚本，就不能一眼看到这个方法接受些什么参数以及参数的个数是多少。比如像下面：

var $ = function(){return document.getElementById(arguments[0]);}

应该改成：var $ = function(elemID){return document.getElementById(elemID);}

 

17、不在语句非赋值地方出现中文

语句中不应该出现中文我想一般人都知道，虽然这样做不影响程序运行，但是显然有背行业标准要求，当然我们也不是在使用“易语言”做开发。关于这一个问题，我本来不想把它拿出来说的，但我确实遇到有人这样做的，也不知道是不是因为他的英语实在太烂了，至少还可以用拼音吧，另外寻求翻译工具帮忙也不错的选择。我举例如下，像以下写法出现在教学中倒还可以理解：

this.user['名字'] = '张三'　或者　this.user.名字 = '张三'

 

18、不必热衷动态事件绑定

虽然知道事件可以动态绑定，比如使用addEventListener或者使用jQuery的bind方法，也知道采用动态事件绑定可以让XHTML更干净，但是一般情况下我还是建议直接把事件写在DOM节点上，我认为这样可以使代码变得更容易维护，因为这样做，我们在查看源代码的时候就可以容易地知道什么Element绑定了什么方法，简单说这样更容易知道一个按钮或链接点击时调了什么方法脚本。

 

19、不在文件中留下未来确定不再使用的代码片段

当代码调整或重构后，之前编写的不再使用的代码应该及时删除，如果认为这些代码还有一定利用价值可以把它们剪切到临时文件中。留在项目中不仅增加了文件体积，这对团队其它成员甚至自己都起到一定干扰作用，怕将来自己看回代码都搞不懂这方法是干什么的，是否有使用过。当然可以用文档注释标签@deprecated把这个方法标识为不推荐的。

 

20、不重复定义其他团队成员已经实现的方法

对于大型项目，一般会有部分开发成员实现一些通用方法，而另外一些开发成员则要去熟悉这些通用方法，然后在自己编写模块遇到有调用的需要就直接调用，而不是像有些开发者喜欢“单干”，根本不会阅读这些通用方法文档，在自己代码中又写了一遍实现，这不仅产生多余的代码量，当然也是会影响团队开发效率的，这是没有团队合作精神的表现，是重复造轮子的悲剧。

比如在通用类文件Common。js有定义function $(elemID){return document.getElementById(elemID)}那么就不应该在Mail.js中再次出现这一功能函数的重复定义，对于一些复杂的方法更应该如此。

 

21、调用合适的方法

当有几个方法都可以实现同类功能的时候，我们还是要根据场景选择使用最合适的方法。下面拿jQuery框架的两个AJAX方法来说明。如果确定服务器返回的数据是JSON应该直接使用$.getJSON，而不是使用$.get得到数据再用eval函数转成JSON对象。如果因为本次请求要传输大量的数据而不得以使用$.post也应该采用指定返回数据类型（设置dataType参数）的做法。如果使用$.getJSON，在代码中我们一眼能看出本次请求服务器返回的是JSON。

温馨提示：jQuery1.4后，如果服务器有设置数据输出的ContentType，比如ASP.NET C#设置 Response.ContentType = "application/json"，那么$.get将与$.getJSON的使用没有什么区别。

 

22、使用合适的控件存储合适的数据

曾发现有人利用li来保存JSON数据，以待页面下载后将来使用，像这样：<li >{ "name":"Tom"}</li>，显然这个li不是用来界面显示的，如果非要这样做，达到使用HTML文件进行数据缓存的作用，至少改成用隐藏域来存这数据更合理，比如改成：<input type="hidden" value=" { "name":"Tom"}" />。

其实也可以利用window对象来保存一些数据，像上面的例子，我们可以在AJAX请求页直接包含这样的脚本块：<script>window.userData = { "name":"Tom"};</script>，当在AJAX请求回调函数中执行完$( "#Myli ").html(data)后，在window上就马上有了这一变量。如果采用第一种方法，将不可避免eval(document.getElementById("UserData").innerHTML)。如果在window对象存放大量数据的话，这些数据不用时要及时手动清理它们，它们是要等浏览器刷新或重启后才会消失的，这就会增加内存开销。

 

23、永远不要忽略代码优化工作

代码最优化是每个程序员应该努力达到的目标，也应该成为程序员永远的追求。写代码的时候，不应该急着把功能实现出来，要想一下如何写代码，代码的执行效率才是较好的。

举个例子：假设有定义getElementById的快捷方法functoin $(elemID){return document.getElementById(elemID)}，那么有人可能会写出这样的代码$("Myli").parentNode.removeChild($("Myli"))，其实这里执行了两次getElementById DOM查找，如果改成这样将更好：var myli = $("Myli"); myli.parentNode.removeChild(myli)。还好getElementById的DOM查找算比较快，如果换成getElementsByTagName则更应该注重优化了。jQuery开发团队也有提醒大家要注意这方面的问题。