1.不要做任何假设
（JavaScript是一个不可靠的助手）
可能不唐突的JavaScript 的最重要的一个特性就是——你要停止任何假设：
* 不要假设JavaScript是可用的，你最好认为它很有可能是不可用的，而不是直接依赖于它。
* 在你经过测试确认一些方法和属性可以使用之前，不要假设浏览器支持它们。
* 不要假设HTML代码如你想象的那样正确，每次都要进行检查，并且当其不可用的时候就什么也不要做。
* 让JavaScript的功能独立于输入设备
* 要记住其他的脚本可能会影响你的JavaScript的功能，所以要保证你的脚本的作用域尽可能地安全。
在开始设计你的脚本之前，要考虑的第一件事情就是检查一下你要为其编写脚本的HTML代码，看看有什么东西可以帮助你达到目的。
2.找出钩子和节点关系
（HTML是脚本的基石）
在开始编写脚本之前，要先看一下你要为之编写JavaScript的HTML。如果HTML是未经组织的或者未知的，那么你几乎不可能有一个好的脚本编写方案——很可能就会出现下面的情况：要么是会用JavaScript创建太多标记，要么就是应用太依赖于JavaScript。
在HTML中有一些东西需要考虑，那就是钩子和节点关系。
<1>.HTML 钩子
HTML最初的和最重要的钩子就是ID，而且ID可以通过最快的DOM方法——getElementById 访问到。如果在一个有效的HTML文档中所有的ID都是独一无二的话（在IE中关于name 和 ID 有一个bug，不过有些好的类库解决了这个问题），使用ID就是安全可靠的，并且易于测试。
其他一些钩子就是是HTML元素和CSS类，HTML元素可以通过getElementsByTagName方法访问，而在多数浏览器中都还不能通过原生的DOM方法来访问CSS类。不过，有很多外部类库提供了可以访问CSS类名（类似于 getElementsByClassName） 的方法。
<2>.HTML 节点关系
关于HTML的另外比较有意思的一点就是标记之间的关系，思考下面的问题：
* 要怎样才可以最容易地、通过最少的DOM遍历来到达目标节点？
* 通过修改什么标记，可以尽可能多地访问到需要修改的子节点？
* 一个给定的元素有什么属性或信息可以用来到达另外一个元素？
遍历DOM很耗资源而且速度很慢，这就是为什么要尽量使用浏览器中已经在使用的技术来做这件事情。
3.把遍历交给专家来做
（CSS，更快地遍历DOM）
有关DOM的脚本和使用方法或属性（getElementsByTagName, nextSibling, previousSibling, parentNode以及其它）来遍历DOM似乎迷惑了很多人，这点很有意思。而有趣的是，我们其实早已经通过另外一种技术—— CSS ——做了这些事情。
CSS 是这样一种技术，它使用CSS选择器，通过遍历DOM来访问目标元素并改变它们的视觉属性。一段复杂的使用DOM的JavaScript可以用一个CSS选择器取代：
复制代码 代码如下:
var n = document.getElementById('nav');
if(n){
var as = n.getElementsByTagName('a');
if(as.length > 0){
for(var i=0;as[i];i++){
as[i].style.color = ‘#369′;
as[i].style.textDecoration = ‘none';
}
}
}
/* 下面的代码与上面功能一样 */
#nav a{
color:#369;
text-decoration:none;
}
这是一个可以好好利用的很强大的技巧。你可以通过动态为DOM中高层的元素添加class 或者更改元素ID来实现这一点。如果你使用DOM为文档的body添加了一个CSS类，那么设计师就很可以容易地定义文档的静态版本和动态版本。
JavaScript:
复制代码 代码如下:
var dynamicClass = 'js';
var b = document.body;
b.className = b.className ? b.className + ' js' : 'js';
CSS:
/* 静态版本 */
#nav {
....
}
/* 动态版本 */
body.js #nav {
....
}
4.理解浏览器和用户
（在既有的使用模式上创建你所需要的东西）
不唐突的JavaScript 中很重要的一部分就是理解浏览器是如何工作的（尤其是浏览器是如何崩溃的）以及用户期望的是什么。不考虑浏览器你也可以很容易地使用JavaScript 创建一个完全不同的界面。拖拽界面，折叠区域，滚动条和滑动块都可以使用JavaScript创建，但是这个问题并不是个简单的技术问题，你需要思考下面的问题：
* 这个新界面可以独立于输入设备么？如果不能，那么可以依赖哪些东西？
* 我创建的这个新界面是否遵循了浏览器或者其它富界面的准则（你可以通过鼠标在多级菜单中直接切换吗？还是需要使用tab键？）
* 我需要提供什么功能但是这个功能是依赖于JavaScript的?
最后一个问题其实不是问题，因为如果需要你就可以使用DOM来凭空创建HTML。关于这点的一个例子就是“打印”链接，由于浏览器没有提供一个非 JavaScript的打印文档功能，所以你需要使用DOM来创建这类链接。同样地，一个实现了展开和收缩内容模块的、可以点击的标题栏也属于这种情况。标题栏不能被键盘激活，但是链接可以。所以为了创建一个可以点击的标题栏你需要使用JavaScript将链接加入进去，然后所有使用键盘的用户就可以收缩和展开内容模块了。
解决这类问题的极好的资源就是设计模式库。至于要知道浏览器中的哪些东西是独立于输入设备的，那就要靠经验的积累了。首先你要理解的就是事件处理机制。
5.理解事件
（事件处理会引起改变）
事件处理是走向不唐突的JavaScript的第二步。重点不是让所有的东西都变得可以拖拽、可以点击或者为它们添加内联处理，而是理解事件处理是一个可以完全分离出来的东西。我们已经将HTML,CSS和JavaScript分离开来，但是在事件处理的分离方面却没有走得很远。
事件处理器会监听发生在文档中元素上的变化，如果有事件发生，处理器就会找到一个很奇妙的对象（一般会是一个名为e的参数），这个对象会告诉元素发生了什么以及可以用它做什么。
对于大多数事件处理来说，真正有趣的是它不止发生在你想要访问的元素上，还会在DOM中较高层级的所有元素上发生（但是并不是所有的事件都是这样，focus和blur事件是例外）。举例来说，利用这个特性你可以为一个导航列表只添加一个事件处理器，并且使用事件处理器的方法来获取真正触发事件的元素。这种技术叫做事件委托，它有几点好处：
* 你只需要检查一个元素是否存在，而不需要检查每个元素
* 你可以动态地添加或者删除子节点而并不需要删除相应的事件处理器
* 你可以在不同的元素上对相同的事件做出响应
需要记住的另一件事是，在事件向父元素传播的时候你可以停止它而且你可以覆写掉HTML元素（比如链接）的缺省行为。不过，有时候这并不是个好主意，因为浏览器赋予HTML元素那些行为是有原因的。举个例子，链接可能会指向页面内的某个目标，不去修改它们能确保用户可以将页面当前的脚本状态也加入书签。
6.为他人着想
（命名空间，作用域和模式）
你的代码几乎从来不会是文档中的唯一的脚本代码。所以保证你的代码里没有其它脚本可以覆盖的全局函数或者全局变量就显得尤为重要。有一些可用的模式可以来避免这个问题，最基础的一点就是要使用 var 关键字来初始化所有的变量。假设我们编写了下面的脚本：
复制代码 代码如下: