一、JS规范 - 引用
统一在文件末尾引入js文件。
二、JS规范 - 命名规范
1、命名
- 常量的形式如:NAMES_LIKE_THIS,全部使用大写字符,并用下划线分隔。你也可用@const标记来指明它是一个常量。但请永远不要使用const关键词。常量定义后就不要去修改
- 变量的命名格式统一使用Camel命名法,即驼峰格式
// badvar user_list = [];// goodvar userList = [];
- 函数、函数的参数都使用Camel命名法
- 类使用Pascal命名法
function TextNode(options) {}
- 类名使用名词
- 函数名使用动宾短语
- boolean型变量使用is,has开头
- Promise对象使用动宾短语的进行时
var loadingData = ajax.get('url');loadingData.then(callback);
2、语法
- 大括号{开始前加一个空格,逗号,和冒号:后面都要加一个空格,等号=等判断符前后都加一个空格,一行中多个表示式之间需要空格(不管是,还是;)。
// badmain{color:#333;}var a=1;var b = 'a',c = 'aa';// goodmain {color: #333;}var a = 1;var b = 'a', c = 'aa';
- if,else,for等之后需要加一个空格,else,else if和前面结束的}同行且两者间空一格。
// badif(a>0){// xxx}else{// xxx}for(var i=0;i<10;i++){// xxx}// goodif (a > 0) {// xxx} else {// xxx}for (var i = 0; i < 10; i++) {// xxx}
- 永远用var声明变量,不加var时,会污染顶层上下文
- 总是加上分号作为结束符
- 操作符与操作算子之间要有空格
// badvar string = 'Foo'+bar;// goodvar string = 'Foo' + bar;
- 使用string 时,用单引号替代双引号(JSON除外)
// badvar foo = "bar";var http = require("http");// goodvar foo = 'bar';var http = require('http');
- 使用===和!==来做比较而不是==和!=
- 使用字面表达式,禁止使用new来创建基础类型变量,用{},[]代替new Array,new Object,不要使用string,bool,number 的对象类型,即不要调用 new String ,new Boolean ,new Number
- 避免使用with与eval,eval仅用于解析序列化串
- 使用this时应当十分小心,要理解清楚this具体指向的是哪个对象
- for-in只用于遍历object,map,hash,不要用于遍历Array
- 不要出现长字符串,尤其是使用变量拼接的字符串,你应该考虑使用其它形式来实现,比如模版
- 函数参数大于3个时,应以对象形式作为参数集传递
- 禁止在代码块中声明函数
// badif (true) {function foo() {}}// goodvar foo = function() {}if (true) {foo();}
- 不要将不同目的的语句,合并成一行
// badif (a = b) {...}var a = b = 0;// gooda = b;if (a) {...}var a = 0;var b = 0;
- 所有变量声明都放在头部,所有函数都在使用之前定义,先写变量,后写函数
- 永远不要把参数命名为 arguments。这将取代函数作用域内的 arguments 对象
- 使用 . 来访问对象的属性,只有当通过变量访问属性时才使用中括号 []
- 使用parseInt时,必须指定进制
// badparseInt(str);// goodparseInt(str, 10);
- undefined,null,0,NaN,’’,false这些表达式会被计算为false,而[],{},’0’,1等会被计算为true,所以在做if判断时我们应当使用简写方式
// badvar a;if (a === null || a === undefined) {// some code}// goodvar a;if (a) {// some code}// badvar b = [];if (b.length > 0) {// some code}// goodvar b = [];if (b.length) {// some code}
- 使用大括号包裹代码段,即使只有1行
// badif (true) return 'a';// goodif (true) {return 'a';}
- 运算符处换行时,运算符必须在新行的行首
// badif (user.isAuthenticated() &&user.isInRole('admin') &&user.hasAuthority('add-admin') ||user.hasAuthority('delete-admin')) {// Code}// goodif (user.isAuthenticated()&& user.isInRole('admin')&& user.hasAuthority('add-admin')|| user.hasAuthority('delete-admin')) {// Code}
3、链式调用
- 鼓励使用链式调用,这样可以使代码更短,思路更清晰,减少变量使用和重复代码
- 链式过长时(一般为超过120列)应当另起一行,另起一行时应当以.开头,强调这是方法调用而不是新语句
// bad$('#items').find('.selected').highlight().end().find('.open').updateCount();// bad$('#items').find('.selected').highlight().end().find('.open').updateCount();// good$('#items').find('.selected').highlight().end().find('.open').updateCount();
4、JSON
- 不要使用关键字、保留字作为键值,例如class,default
- json对象的最后一个不要有逗号,
// badvar students = [{name: '',age: 12,}, {name: '',age: 13,},]// goodvar students = [{name: '',age: 12}, {name: '',age: 13}]
5、jQuery
使用 $ 作为存储 jQuery 对象的变量名前缀
// badvar sidebar = $('.sidebar');// goodvar $sidebar = $('.sidebar');
- 缓存jQuery查询,超过一次以上调用就需要用变量缓存,避免再次执行DOM查询而浪费内存
// badfunction setSidebar() {$('.sidebar').hide();// ...stuff...$('.sidebar').addClass('js-active');}// goodfunction setSidebar() {var $sidebar = $('.sidebar');$sidebar.hide();// ...stuff...$sidebar.addClass('js-active');}
- 不要使用js来控制元素的样式,而应该是通过增减class来实现
// bad$dom.css({color: '#fff'});// good// css中添加.js-white {color: #fff;}$dom.addClass('js-white');
- 自定义的事件名全小写,使用命名空间配合.来连接
$dom.trigger('modal.opening');
- 设置元素的checked,disabled等状态时建议使用原生的js方法去改,而不是使用jquery的attr方法
// bad$dom.attr('checked', 'checked');// good$dom[0].checked = true;
6、安全
- 禁止使用站外资源,因为这些站外资源不可控
- 警惕xss, csrf等安全性漏洞攻击
7、注释
文件注释
文件的注释中要包含作者信息,使用@author标识。
开发者信息能够体现开发人员对文件的贡献,并且能够让遇到问题或希望了解相关信息的人找到维护人。通常情况文件在被创建时标识的是创建者。随着项目的进展,越来越多的人加入,参与这个文件的开发,新的作者应该被加入@author标识。
@author标识具有多人时,原则是按照 责任 进行排序。通常的说就是如果有问题,就是找第一个人应该比找第二个人有效。比如文件的创建者由于各种原因,模块移交给了其他人或其他团队,后来因为新增需求,其他人在新增代码时,添加 @author 标识应该把自己的名字添加在创建人的前面。
@author中的名字不允许被删除。任何劳动成果都应该被尊重。
业务项目中,一个文件可能被多人频繁修改,并且每个人的维护时间都可能不会很长,不建议为文件增加 @author 标识。通过版本控制系统追踪变更,按业务逻辑单元确定模块的维护责任人,通过文档与wiki跟踪和查询,是更好的责任管理方式。
对于业务逻辑无关的技术型基础项目,特别是开源的公共项目,应使用@author标识。
/** * @file Describe the file * @author author-name(mail-name@domain.com) * author-name2(mail-name2@domain.com) */
