【前端】开发指南

避免污染全局命名空间

过分依赖全局变量是我们组所有人 -- 特别是我自己 -- 特别有负罪感的一件事。关于为啥全局变量不好的讨论是相当直接的：这增加了脚本和变量冲突的概率，而且源文件和命名空间本身都会充斥着数不清的命名模糊的变量。

Douglas Crockford 坚信一个Javascript应用的代码质量可以用其中使用的全局变量数来评价，越少越好。由于并不是什么都可以定义成local的（不过要诚实，其实你现在考虑的那个是可以的，别偷懒），你需要想办法整理你的变量以避免冲突，并把命名空间的膨胀减到最小。最简单的方法就是采用单变量或者把用到这些全局变量的模块尽可能减少。 Crockford提到YUI只用了一个全局变量，YAHOO。他在他的博文 "全局统治" 中讨论了更多的细节问题。

考虑这种情况：对于小型web应用，全局变量通常用于保存应用级的设置，可以用你的项目名或者settings作为命名去定义一个对象，这样总的来说会更好。

// 被污染的全局命名空间
var settingA = true;
var settingB = false;
var settingC = "test";

// 用 settings 作为对象命名
var settings = {
    settingA: true,
    settingB: false,
    settingC: "test"
}

不过，如果我们可以通过避免使用全局变量来减少冲突概率，但是把命名空间标准化成一样的，岂不是会增加各个应用之间产生冲突的概率么？呃，这个担忧确实有道理。所以，建议你用自己特定的应用名作为全局变量的命名空间，或者用和jQuery采取的 $.noConflict() 模式相同的方法重新分配你的命名空间.

var myAppName = {
    settings: {
        settingA: true
    }
}

//访问全局变量
myAppName.settings.settingA; // true

驼峰法变量命名

JavaScript变量的驼峰法命名在大部分编程环境中都是作为标准的。有读者在评论中提出了唯一的例外，就是要用大写字母加下划线来指代常量。

var X_Position = obj.scrollLeft;

var xPosition = obj.scrollLeft; // 更好，更简洁

SCENE_GRAVITY = 1; // 常量

循环的性能 - 缓存数组长度

循环估计是Javascript性能调优最重要的部分了。在一个循环内部节省个一两毫秒的，说不定总体就省出好几秒来了。这里有一招就是把数组的长度缓存，这样在循环里就无需每次迭代的时候都计算一遍了。

var toLoop = new Array(1000);

for (var i = 0; i < toLoop.length; i++) {
    // 败家玩意 - 长度会反复算 1000 次你知道不？
}

for (var i = 0, len = toLoop.length; i < len; i++) {
    // 会过日子 - 长度只计算一次，然后缓存了
}

例外

如果你对一个数组做循环来查找并删除某个元素，这就会改变数组长度。任何时候你只要会在循环内部增加或删除元素来改变数组的长度，你就给自己带来了麻烦。这种情况下，你要么每次改变后重新设置数组长度，要么就别缓存它了。

循环的性能 - 使用 ‘break;’ 和 ‘continue;’

跳过和跳出循环的能力对于避免开销很大的循环周期是非常有用的。

如果你是在循环内部查找，查找成功以后你会做什么？比如1000个元素的循环执行到一半，你就找到了你要的东西。你不管三七二十一，即使知道后面的if语句不会再有符合的机会，还是让循环继续把剩下的500个元素迭代完么？不！你应该跳出循环，必须的！

var bigArray = new Array(1000);

for (var i = 0, len = bigArray.length; i < len; i++) {
    if (i === 500) {
        break;
    }
    console.log(i); // 这样只会输出 0 - 499
}

另一个问题是跳过某个特定的迭代，然后继续循环。虽然说类似于奇偶数这样的条件可以通过把 i++ 替换成 i + 2 的办法来管理，有些条件还是需要具体检测，然后触发跳过操作。任何能够避免执行完整的迭代过程的东西都是很有用的。

var bigArray = new Array(1000);

for (var i = 0, len = bigArray.length; i < len; i++) {
    if (condition) {
　　　　　// continue是跳过本次循环
        continue;
    }
    doCostlyStuff();
}
 

函数调用不要传输太多的参数

对于可读性而不是其他因素来说，下面这种方式真是糟透了：

function greet(name, language, age, gender, hairColour, eyeColour) {
    alert(name);
}

下面的例子预先构建了一个对象作为参数，或者把内联对象传递过去，这样就好多了。

function greet(user) {
    alert(user.name);
}

greet({
    name: "Bob",
    gender: "male"
});

把 ‘this’ 映射为 ‘self’

在编写面向对象（OO）Javascript代码的时候, 必须了解 this 的作用范围. 不管你用来构建伪类的设计模式是什么，对 this 的引用是指向一个实例的最简单办法。当你开始把jQuery的helper方法和你的伪类集成的时候，你就会注意到 this 的作用范围变化。

Bob.findFriend("Barry");

Person.prototype.findFriend = function(toFind) {
    // this = Bob
    $(this.friends).each(function() {
        // this = Bob.friends[i]
        if (this.name === toFind) {
            // this = Barry
            return this;
        }
    });
}

在上面的例子里， this 经历了从对 Bob 的引用，变成对他的朋友 Barry 的引用的过程。 了解 this 的取值在一段时间发生的变化是很重要的。在原型函数内部， this 指向所在伪类的当前实例（这里是 Bob ）。而一旦我们进入 $.each() 循环， this就会重新映射为被解析数组的第 i 个元素。

解决办法是把 this 的值重新映射为 self 或者 _self。虽然 self （不带下划线）并不是 保留字, 但它 确实是 window 对象的一个属性。虽然我上面用到 self 的例子是从jQuery源代码中挑的，但他们也认识到了这个错误，正打算 修正目前的状况 ，也就是改用 _self。我个人还是喜欢用 self ，不为别的，就因为它的简洁 -- 不过它可能会冒出一些非常令人困惑的bug。总之，用 self 有风险，使用需谨慎。

在下面的例子中，我会更好地利用在 $.each() helper 中提供的参数，同时重新映射 this 的值。

Bob.findFriend("Barry");

Person.prototype.findFriend = function(toFind) {

    // 就这一次用到了 "this"
    var _self = this;

    $(_self.friends).each(function(i,item) {
        if (item.name === toFind) {
            return item;
        }
    });

}