可用性
咋地了, DOCTYPE?
不定义DOCTYPE是一种可以被判死刑的罪行。 以前你可能用的是下面的DOCTYPE，不过你要知道现在已经有更简洁清晰的代码取而代之了。
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
理想的状况是用HTML5 DOCTYPE，所有现代的浏览器都支持它，即使是不支持HTML5的浏览器，例如IE6,IE7，也会由此转入标准模式。
<!DOCTYPE html>
编写合法且语义清晰的标记
用整洁、语义清晰的HTML编写网站代码是我们一直孜孜以求的。有时我们会发现前人配置页面的方式限制了我们，或者有时我们编写的是HTML格式的email模板。但永远不要偏离HTML的规范，即使是为了解决特定浏览器兼容性的bug。
所有的标题应该从<h2>开始分层级创建，文字段落应该总是放在<p>标签里，诸如此类。如果你编写的HTML的语义清晰，产生的页面会更整洁、简练，而且易于被搜索引擎爬虫解析。这是你能做到的最简单的SEO修补方式。
来看看下面的段落，你觉得哪个更整洁？是这个？
<span class="sectionHeading">A Heading</span> <br /> <br /> Lorem ipsum dolor sit amet. ... <br /> <br />
还是这个？
<h2>A Heading</h2>
<p>
Lorem ipsum dolor sit amet. ...
</p>
鼠标中键点击的应变方式
现代web应用最令人郁闷的可用性缺陷之一是超链接功能的变种。 一些看起来像是超链接的元素可能是通过Javascript映射的单击功能，这就破坏了鼠标中键点击（在新的tab中打开链接页面）的功能。即使它们能在新的标签页打开，它们只带有一个
# 的href又会把你带回到同样的页面。
深刻诠释了该问题的一个现代热门网站的例子就是Twitter。在它的整个应用里，鼠标中键点击用户名或头像会得到完全不同的结果。
<!-- 旧的方式，破坏网页语义 --> <a href="#"></a> <!-- 如果鼠标点击不能产生一个页面，那就不是超链接 --> <span class="link" role="link"></span>
另一个替代方案是使用 # 引导的路径，它会把普通的url映射为 # 引导的链接，然后通过AJAX来获取页面片段。提供此功能的库应该能够在鼠标中键点击的时候正常显示页面，或者在左键点击时把该页面内容加载到指定的区域。不过这样也要慎重行事，有很多人都认为链接正在破坏web应用。
用Microformats格式表示联系人信息
Microformat是一种便于机器读取联系人信息的方式。hCard类（不是vCard）用来定义元素里包含的内容类型。这些内容会被浏览器提取并突出显示。
<span class="tel">
<span class="type">home</span>:
<span class="value">+1.415.555.1212</span>
</span>
如果你曾经浏览采用此格式的网页，你会注意到类似skype的程序可以轻松检测到网页上的哪些数字是电话号码。在iOS设备上的Safari浏览器也可以做到类似的事情。
只对表格数据用table标签
table标签永远只应该用在表格数据的展示上。唯一的例外是当编写HTML格式的邮件时，这种情况下可能table是某些坑爹的邮件客户端唯一支持的样式了。
为了可读性，表格头永远要使用 <th> 元素。同时切记要设置cellpadding, cellspacing 和 border 的值为 0 ， 因为这些样式由CSS来控制更容易确保一致性。
<table cellpadding="0" cellspacing="0" border="0">
<thead>
<tr>
<th>
Cell Header
</th>
</tr>
</thead>
<tbody>
<tr>
<td>
Cell Item
</td>
</tr>
</tbody>
</table>
JavaScript
代码留空和格式
任何关于代码格式、留空和大括号位置的讨论都会引起激烈辩论。对此，我想最简单的规则就是，除非你愿意把整个代码文件重新格式化，不然还是尊重并保持已有代码文件的格式。这意味着如果你看到一个JS文件里的大括号没有换行写，那你的代码也要继续保持大括号不换行。如果你的代码没有和代码文件里的其他部分保持一致，那么你的代码就不应该通过代码审查流程。
一致的代码格式让代码更加易读，同时也意味着代码容易用查找/替换命令进行修改。谢天谢地，我们自己形成的编程习惯和jQuery正式推荐的方式非常相似。细微的差异也是有的，不过，那些是个人问题或者我们觉得没法维护的一些东西。
字符间距
// 不好
if(blah==="foo"){
foo("bar");
}
// 好 :)
if (blah === "foo") {
foo("bar");
}
大括号不换行
// 不好
if (foo)
{
bar();
}
// 好 :)
if (foo) {
bar();
}
总是用大括号
// 不好
if (foo)
bar();
// 好 :)
if (foo) {
bar();
}
字符串处理
引用字符串永远要用双引号。 有些人非常喜欢用C语言风格的字符串（单引号），但这种习惯会导致脚本内部的风格冲突。C语言风格的字符串处理要求空字符串和单字符包在单引号里，而短语和单词必须包在双引号内。
注释
往代码里玩命加注释的需求是由各种经理、主管及其他很少接触代码的人们引领的。这种需求无非是雇员们考核指标中的一个勾选栏，花在这上面的时间基本没有带来什么回报。 如果那些从善如流的开发者能遵循本文档中提出的建议，他们的代码会变得相当易于阅读，一目了然，以至于再用注释描述这些代码会多余得令人尴尬。来看下面的例子。在这里，布尔变量被作为问题提出，而函数也有直观的命名。
if (user.hasPermission) {
editPage();
}
至少在这个场景中，注释是完全没有必要的。
注释重要的情况
一个项目里，永远会有某些部分难以查阅和理解。比如一个复杂的正则表达式，或者一个对角度进行计算或在度和弧度单位之间切换的数学函数。没有上面的注释，初级或中级的读者将对脚本的含义毫无头绪。
// 校验美国电话号码的正则表达式，号码格式是 (XXX) XXX-XXXX (减号、空格和括号都是可选的，可以有也可以没有)
var phoneRegEx = /^\(?(\d{3})\)?[- ]?(\d{3})[- ]?(\d{4})$/;
总是使用 === 比较符
使用 == 比较符可以让令人郁闷的bug消失于无形。使用严格的 === 比较符不会执行类型强制转换，从而能够严格地评估两个对象之间的差别。
var zeroAsAString = "0";
if (zeroAsAString == 0) {
// 这样也能判断为true，呵呵...
}
if (zeroAsAString === 0) {
// 判断为false
}
例外
在和null进行比较的时候，允许使用 == 比较符，因为它会检测null和undefined两个属性。如果你不完全理解这个原理，那我还是建议你用 === 比较符为好。
var foo = null;
// foo 是 null, 但 bar 是 undefined ，因为它尚未被声明
if (foo == null && bar == null) {
// 上面的判断还是成立的
}
使用 .parseInt() 的时候，总是指定第二个 ‘radix’ 参数
把字符串解析为整数的时候，有个好习惯是指定第二个基数参数 -- 它会确定该字符串被转换成几进制。当字符串以
0 开头的时候，缺省情况下会触发 16 进制作为基数。大部分初级和中级用户只会用到 10 这个基数。
alert( parseInt("08") ); // alerts: 2
alert( parseInt("08", 10) ); // alerts: 8
避免比较 true 和 false
直接比较 true 和 false 的值是没有必要的。有时候也许明确一下有好处，但它还是额外的代码。
if (foo === true) {
// 用了 === 倒是不错，可这是多余的
}
if (foo) {
// 赞！
}
if (!bar) {
// 反过来也赞
}
避免污染全局命名空间
过分依赖全局变量是我们组所有人 -- 特别是我自己 -- 特别有负罪感的一件事。关于为啥全局变量不好的讨论是相当直接的：这增加了脚本和变量冲突的概率，而且源文件和命名空间本身都会充斥着数不清的命名模糊的变量。
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;
}
});
}
我能用 Boolean 吗？
布尔变量必须能够很容易通过命名来识别。可以用类似于
is, can 或者 has 的前缀来形成一个问句。
isEditing = true; obj.canEdit = true; user.hasPermission = true;
MT.Team