编码规范

空格与格式

1. 缩进

采用2个空格缩进，而不是tab缩进。 空格在编辑器中与字符是等宽的，而tab可能因编辑器的设置不同。2个空格会让代码看起来更紧凑、明快。

2. 变量声明

永远用var声明变量，不加var时会将其变成全局变量，这样可能会意外污染上下文，或是被意外污染。 在ECMAScript 5的strict模式下，未声明的变量将会直接抛出ReferenceError异常。

需要说明的是，每行声明都应该带上var，而不是只有一个var，示例代码如下：

var assert = require(‘assert‘);var fork = require(‘child_process‘).fork;var net = require(‘net‘);var EventEmitter = require(‘events‘).EventEmitter;

错误示例如下所示：

var assert = require(‘assert‘)  , fork = require(‘child_process‘).fork  , net = require(‘net‘)  , EventEmitter = require(‘events‘).EventEmitter;

3. 空格

在操作符前后需要加空格，比如+、-、*、%、=等操作符前后都应该存在一个空格，示例如下：

var foo = ‘bar‘ + baz;

错误的示例如下所示：

var foo=‘bar‘+baz;

此外，在小括号前后应该存在空格，如：

if (true) {  // some code}

错误的示例如下所示：

if(true){  // some code}

4. 单双引号的使用

由于双引号在别的场景下使用较多，在Node中使用字符串时尽量使用单引号，这样无需转义，如：

var html = ‘<a href="http://cnodejs.org">CNode</a>‘;

而在JSON中，严格的规范是要求字符串用双引号，内容中出现双引号时，需要转义。

5. 大括号的位置

一般情况下，大括号无需另起一行，如

if (true) {  // some code}

错误的示例如下：

if (true){  // some code}

6. 逗号

逗号用于变量声明的分隔或是元素的分隔。如果逗号不在行结尾，前面需要一个空格。此外，逗号不允许出现在行首，比如： var foo = ‘hello‘, bar = ‘world‘; // 或是 var hello = { foo: ‘hello‘, bar: ‘world‘ }; // 或是 var world = [‘hello‘, ‘world‘];错误示例如下：

var foo = ‘hello‘  , bar = ‘world‘;// 或是var hello = {foo: ‘hello‘  , bar: ‘world‘};// 或是var world = [  ‘hello‘  , ‘world‘];

7. 分号

给表达式结尾添加分号。尽管JavaScript编译器会自动给行尾添加分号，但还是会带来一些误解，示例如下：

function add() {  var a = 1, b = 2  return    a + b}

将会得到undefined的返回值。因为自动加入分号后会变成如下的样子：

function add() {  var a = 1, b = 2;  return;    a + b;}

后续的a + b将不会执行。

而如下的代码：

x = y(function () {}())

执行时会得到：

x = y(function () {}())

由于自动添加分号可能带来未预期的结果，所以添加上分号有助于避免误会。

命名规范

在编码过程中，命名是重头戏。好的命名可以令代码赏心悦目，带来愉悦的阅读享受，令代码具有良好的可维护性。命令的主要范畴有变量、常量、方法、类、文件、包等。

1. 变量命名

变量名都采用小驼峰式命名，即除了第一个单词的首字母不大写外，每个单词的首字母都大写，词与词之间没有任何符号，如：

var adminUser = {};

错误的示例如下：

var admin_user = {};

2. 方法命名

方法命名与变量命名一样，采用小驼峰式命名。与变量不同的是，方法名尽量采用动词或判断性词汇，如：

var getUser = function () {};var isAdmin = function () {};User.prototype.getInfo = function () {};

错误示例如下：

var get_user = function () {}; var is_admin = function () {}; User.prototype.get_info = function () {};

3. 类命名

类名采用大驼峰式命名，即所有单词的首字母都大写，如：

function User {}

4. 常量命名

作为常量时，单词的所有字母都大写，并用下划线分割，如：

var PINK_COLOR = "pink";

5. 文件命名

命名文件时，请尽量采用下划线分割单词，比如child_process.js和string_decode.js。如果你不想将文件暴露给其他用户，可以约定以下划线开头，如_linklist.js。

6. 包名

也许你有贡献模块并将其打包发布到NPM上。在包名中，尽量不要包含js或node的字样，它是重复的。包名应当适当短且有意义的，如：

var express = require(‘express‘);

比较操作

在比较操作中，如果是无容忍的场景，请尽量使用===代替==，否则你会遇到下面这样不符合逻辑的结果：

‘0‘ == 0; // true‘‘ == 0 // true‘0‘ === ‘‘ // false

此外，当判断容忍假值时，可以无需使用===或==。在下面的代码中，当foo是0、undefined、null、false、‘‘时，都会进入分支：

if (!foo) {  // some code}

字面量

请尽量使用{}、[]代替new Object()、new Array()，不要使用string、bool、number对象类型，即不要调用new String、new Boolean和new Number。

作用域

在JavaScript中，需要注意一个关键字和一个方法，它们是with和eval()，容易引起作用域混乱。

1. 慎用with

示例代码如下：

with (obj) {  foo = bar;}

它的结果有可能是如下四种之一：obj.foo = obj.bar;、obj.foo = bar;、foo = bar;、foo = obj.bar;，这些结果取决于它的作用域。如果作用域链上没有导致冲突的变量存在，使用它则是安全的。但在多人合作的项目中，这并不容易保证，所以要慎用with。

2. 慎用eval()

慎用eval()的原因与with相同。如果不影响作用域上已存在的变量，用它是安全的。另外，利用eval()的这个特性，也可以玩出一些好玩的特性来，比如wind.js利用它实现了流程控制。在大多数情况下，基本上轮不到eval()来完成特殊使命。示例代码如下：

var obj = {  foo: ‘hello‘,  bar: ‘world‘};var key = (Math.round(Math.random() * 100) % 2 === 0) ? ‘foo‘ : ‘bar‘;var value = http://www.mamicode.com/eval(‘(obj.‘ + key + ‘)‘);

上述代码多出现在新手中，实际只要如下一行代码即可完成：

var value = http://www.mamicode.com/obj[key];

数组与对象

在JavaScript中，数组其实也是对象，但是两者在使用时有些细节需要注意。

1. 字面量格式

创建对象或者数组时，注意在结尾用逗号分隔。如果分行，一行只能一个元素，示例代码如下：

var foo = [‘hello‘, ‘world‘];var bar = {  hello: ‘world‘,  pretty: ‘code‘};

错误示例如下所示：

var foo = [‘hello‘,‘world‘];var bar = {  hello: ‘world‘, pretty: ‘code‘};

2. for in循环

使用for in循环时，请对对象使用，不要对数组使用，示例代码如下：

var foo = [];foo[100] = 100;for (var i in foo) {  console.log(i);}for (var i = 0; i < foo.length; i++) {  console.log(i);}

在上述代码中，第一个循环只打印一次，而第二个循环则打印0~100，这并不满足预期值。

3. 不要把数组当做对象使用

尽管在JavaScript内部实现中可以把数组当做对象来使用，如下所示：

var foo = [1, 2, 3];foo[‘hello‘] = ‘world‘;

这在for in迭代时，会得到所有值：

for (var i in foo) {  console.log(foo[i]);}

也许你只是想得到hello而已。

异步

在Node中，异步使用非常广泛并且在实践过程中形成了一些约定，这是以往不曾在意的点。

1. 异步回调函数的第一个参数应该是错误指示

并不是所有回调函数都需要将第一个参数设计为错误对象。但是一旦涉及异步，将会导致try catch无法捕获到异步回调期的异常。将第一个参数设计为错误对象，告知调用方是一个不错的约定。示例代码如下：

function (err, data) {};

这个约定被很多流程控制库所采用。遵循这个约定，可以享受社区流程控制库带来的业务编写便利。

2. 执行传入的回调函数

在异步方法中一旦有回调函数传入，就一定要执行它，且不能多次执行。如果不执行，可能造成调用一直等待不结束，多次执行也可能会造成未期望的结果。

类与模块

关于如何在JavaScript中实现继承，有各种各样的方式，但在Node中我们只推荐一种，那就是类继承的方式。另外，在Node中，如果要将一个类作为一个模块，就需要在意它的导出方式。

1. 类继承

一般情况下，我们采用Node推荐的类继承方式，示例代码如下：

function Socket(options) {  // ...  stream.Stream.call(this);  // ...}util.inherits(Socket, stream.Stream);

2. 导出

所有供外部调用的方法或变量均需挂载在exports变量上。当需要将文件当做一个类导出时，需要通过如下的方式挂载：

module.exprots = Class;

而不是通过

exports = Class;

私有方法无需因为测试等原因导出给外部，所以无须挂载。

注解规范

一般情况下，我们会对每个方法编写注释，这里采用dox的推荐注释，示例如下：

/** * Queries some records * Examples: * ``` * query(‘SELECT * FROM table‘, function (err, data) { * // some code * }); * ``` * @param {String} sql Queries * @param {Function} callback Callback */exports.query = function (sql, callback) {  // ...};

dox的注释规范源自于JSDoc。可以通过注释生成对应的API文档。

最佳实践

细致的编码规范有很多，有争议的也少，但这并不阻碍我们找到共同点。

冲突的解决原则

如果你要贡献部分代码给某个开源项目，而它的编码规范与你并不相同，这种情况下需要采用入乡随俗的原则，尽量遵循开源项目本身的编码规范而不是自己的编码规范。

给编辑器设置检测工具

实际上，现在的编辑器基本上都可以通过安装插件的方式将JSLint或者JSHint这样的代码质量扫描工具集成进开发环境中，这样编码完成后就可以及时得到提示。

如果采用的是Sublime Text 2编辑器，在安装好插件后，可以在项目中配置.jshintrc文件，每次保存都会在编辑器中提醒不规范的信息。

如下是我某个项目的.jshintrc文件，仅供参考：

{  "predef": [    "document",    "module",    "require",    "__dirname",    "process",    "console",    "it",    "xit",    "describe",    "xdescribe",    "before",    "beforeEach",    "after",    "afterEach"  ],  "node": true,  "es5": true,  "bitwise": true,  "curly": true,  "eqeqeq": true,  "forin": false,  "immed": true,  "latedef": true,  "newcap": false,  "noarg": true,  "noempty": true,  "nonew": true,  "plusplus": false,  "undef": true,  "strict": false,  "trailing": false,  "globalstrict": true,  "nonstandard": true,  "white": true,  "indent": 2,  "expr": true,  "multistr": true,  "onevar": false,  "unused": "vars",  "swindent": false}

版本控制中的hook

另一种最佳实践是在版本控制工具中完成的。无论SVN还是Git，都有precommit这样的钩子脚本，通过在提交时实现代码质量的检查。如果质量不达标，将停止提交。

持续集成

持续集成包含两个方面：一方面仍是代码质量的扫描，可以选择定时扫描，或是触发式扫描；另一方面可以通过集中的平台统计代码质量的好坏变化趋势。根据统计结果可以判定团队中的个人对编码规范的执行情况，决定用宽松的质量管理方式还是严格的方式。

总结

代码质量关乎产品的质量，最容易改进的地方即是编码规范，收效也是最高的，它远比单元测试要容易付诸实践。一旦团队制定了编码规范，就应该严格执行，严格杜绝团队中编码规范拖后腿的现象。

也许可以采用CoffeeScript的方式来避免编码规范的问题，但是我相信在使用CoffeeScript之前，了解这些规范会更好地帮助你理解CoffeeScript。

如果你还采用非编译式JavaScript来编写你的应用，请记住这些编码规范。尽管因为历史原因无法一步到位改进这些缺点，但是既然知晓何为优秀，何为糟粕，就应该将优秀当做一种习惯。

选自朴灵的图书《深入浅出Node.js》

参考地址：http://www.ituring.com.cn/article/197990

Node 编码规范（优秀是一种习惯）