代码检查

工作几年以来，从写代码到review代码，从一人开发到多人合作，在如何写代码的问题上确实遇到了不少的困扰。

10年之前，由于压缩工具未普及，很多人都会把压缩代码的习惯带到开发中，于是出现了各种以单个字母命名的变量，比如var a=1;，还有一个var定义一堆变量的情况。

var a = 1,
    b = 2,
    ...
    c = 3;

这类边写代码边考虑压缩的情况，渐渐地衍生为各种奇淫技巧，埋坑无数。代码本身的可维护性和性能是第一位的，压缩、自动优化这类事情还是交给工具来做吧。

从CLOSURE COMPILER到jsLint，再到jsHint，还有现在的eslint，完善的代码检查工具很大程度上完善了工作流，如果你现在的开发流中没有使用到这些工具，那么建议你回头看下自己写的代码，是否存在优化空间。

这里主要不是介绍这些工具，而是从这些工具的角度，来看如何来写更优的代码。

代码检查主要做的就是暴露出以下几类问题：

1. 可能会导致错误的代码
2. 最佳实践
3. 变量声明和使用
4. 针对nodeJs部分的检查
5. 代码风格的检查

下面会简单挑选几个点讲一下，不赘述，纯属偷懒。。。

可能会导致错误的代码

这个比较好理解，比如类似console或者debugger这样的关键词，不应该在发布代码中出现。

这里介绍一些比较容易被忽略的写法。

多余的逗号

对象字面量中多写了一个,比如：

var foo = {
    bar: "baz",
    qux: "quux", //多余的逗号
};

这样的写法在IE6/7下会报错，虽然现在IE6、7占比急剧下降，不过好的代码习惯还是保留着吧。

保留字

代码中无意间使用了保留字，比如：

var values = {
    enum: ["red", "blue", "green"]  //使用关键词enum，IE8下报错
}

不正确地使用NaN

if (foo == NaN) {
    // ...
}

应该写为：

if (isNaN(foo)) {
    // ...
}

最佳实践

最佳实践更多是提供一些优化的建议，比如去掉多余的判断，减少逻辑复杂度这类。

减少逻辑复杂度

避免if(true)这样的代码，还有比如：

function foo() {
    if (x) {
        return y;
    } else {
        return z;
    }
}

可以简化成：

function foo() {
    if (x) {
        return y;
    }
    return z;
}

这个例子还不够通用，比如我们经常会遇到的情况是这样的：

function foo(name){
    if(name === 'a'){
        return 'b'
    } elseif (name === 'c'){
        return 'd'
    } else if
    ....
}

可以改成

var relationData = {
    a: 'b',
    c: 'd',
    ....
};

function foo(name){
    return relationData[name]
}

prototype有修改导致for in结果不符合预期

也有一些容易踩坑的点，比如for in后面检查hasOwnProperty。

设计你的UI

一些不推荐的方法也尽量不使用，比如alert、confirm这类丑爆的默认UI。

减少理解难度

像var num = -.7;这样存在理解难度的代码也尽量避免。

而由于JavaScript变量声明的特殊性，存在作用域中声明前置的情况（被当做各种面试题虐人），最好写代码的时候，在使用之前声明代码，这样会减少理解的成本。

function foo(){
    first();
    function first(){
        //do something..
    }
}

变量声明和使用

try catch可能导致的问题

JavaScript变量部分的坑还是挺多的。比如IE8及之前的版本catch的变量会覆盖同作用域下的同名变量。

var err = "x";

try {
    throw "problem";
} catch (err) {

}

console.log(err)    // 输出'problem'， 而不是'x'

注意命名

上下级不同作用域内不要使用同名的变量。

var a = 3;
function b() {
    var a = 10;
}

node.js

避免同步操作

node里没有什么特别的地方，就是虽然node提供了一些同步处理的方法，但是还是不推荐使用。比如

fs.existsSync(somePath);
var contents = fs.readFileSync(somePath).toString();

一般不会用到非要用同步方法的情况，如果只是为了保证顺序或者写法简单，可以用generator代替。

代码风格

代码风格就略过了，保证这块统一最简单的方法就是统一编辑器，然后统一格式化的方式，比如我用的Idea，就可以直接自动对代码进行排版。至于1个tab是2个空格还是4个空格的问题，团队统一就行，不多讨论。

最后

代码检查的目的最主要的还是提高代码质量，本质上代码检查也是自动化测试中不可获取的重要部分，对于问题的排查也会带来很大的帮助。

推荐阅读w3cplus整理的代码风格周刊，可以了解更多更加完善的代码风格讨论。

不过最终，工具只是辅助，多花时间思考如何写出更好的代码，如何化繁为简，才是真正的目标，也是我一直努力的方向。

参考

• Terrible JavaScript Mistakes To Avoid With A Static Code Analyzer
• eslint
• CLOSURE COMPILER
• jsLint
• jsHint
• ES6 入门
• w3cplus整理的代码风格周刊