经验总结：5个应该避免的前端糟糕实践

这几天在产品的某个模块上上添加新功能，该模块之前是由其他同事维护。也就是说，需要在同事原有代码的基础上进行修改。过程中遇到了一些坑，主要是由一些不合理的代码实践导致的。

这里抛开大的设计话题，仅挑出其中一些自己认为不是很合理的代码细节。原因很简单：当我们在审视别人代码的时候，总会看到这样那样的不合理之处，而等到自己撸起袖子上阵时，其实也很难保证自己不会犯同样的错误。可能是一时偷懒，也可能是赶需求导致的考虑步骤等。

本文代码示例：点击下载

糟糕实践一：依赖节点之间的顺序

我们来看下面代码，大家应该对这样的代码非常熟悉了，这也是初学者比较容易犯的一个错误：节点的查询依赖于节点当前所处的位置。下面 

getElementsByTagName('span')[0] 这样的写法存在很大的隐患，很简单，主要节点的顺序一发生变化，就出事了。

<h2>不要依赖节点顺序</h2>
<div id="1111">
    <span></span>，
    <span>爱好：动漫</span>
</div>

<script type="text/javascript">
    var $ = function(id) {
        return document.getElementById(id);
    }
    $('1111').getElementsByTagName('span')[0].innerHTML = '昵称：程序猿小卡';
</script>

比如节点的顺序变成，那就会发生一些意料之外的事情了，第一个span节点之间的“简介：”就被无情地覆盖了。

<h2>不要依赖节点顺序</h2>
<div id="222">
    <span>简介：</span>
    <span></span>，
    <span>爱好：动漫</span>
</div>

解决方案

千万不要用 element.getElementsByTagName(tagName)[index] 这样的方式可以来获取节点，除非你有非这样做不可的理由。

取而代之可以用类似 element.getElementById(id) 来获取，或者采用下文提到的 element.querySelector(selector) 这样的方式~

糟糕实践二：依赖标签的排版

 上面我们已经提到说节点查询的时候不要依赖于节点的顺序，原因是节点的顺序是有可能改变的。那么，如果节点顺序没有“发生变化”，那就能够确保平安无事了吗？答案是未必。

且看下面的代码，也是很常见的代码，获得id为“333”的元素的第一个子节点，并将该子节点的color设置为 #ccc。

<h2>顺序没变，但脚本错误了</h2>
<div id="333"><span>昵称：程序猿小卡</span><span>爱好：动漫</span></div>

<script type="text/javascript">

    $('333').childNodes[0].style.color = '#ccc';

</script>

顺序不变也会出事？可能有的同学会有这样的疑惑。好吧，本人稍微有一点排版上的强迫症，看上上面类似的标签排班时，总是忍不住想要去小小调整下，好让标签看上去更清晰些，于是我小小调整了下排版，变成下面这个样子。

<h2>顺序没变，但脚本错误了</h2>
<div id="444">
    <span>昵称：程序猿小卡</span>
    <span>爱好：动漫</span>
</div>
<script type="text/javascript">

    $('444').childNodes[0].style.color = '#ccc';

</script>

子节点顺序并没有发生改变，只是排版变了，按理来说不会有什么影响吧。好，让我们打开chrome看下，控制台下输出这样的信息：

Uncaught TypeError: Cannot set property 'color' of undefined 

什么原因呢？眼尖的同学可能已经看出来了，childNodes属性可以获得一个节点的所有子节点，而这些子节点里面包含了文本节点，甚至是标签末尾的换行、空格。不难想到，下面的标签同样会导致同样的bug，而这里的标签跟最初的标签，唯一的区别仅在于：第一个span标签前面多了个空格。

这个bug隐蔽指数相当高，很可能放在那里几年都没有人触发。毕竟，有谁会想到，换个行，加个空格都会导致出bug呢，而且在旧版本IE里面，childNodes是将文本节点排除在外的，也就是说，即使你加了换行、排版，在旧版本IE里测试也是完全ok的，巨坑。

<h2>顺序没变，但脚本错误了</h2>
<div id="555"> <span>昵称：程序猿小卡</span><span>爱好：动漫</span>
</div>
<script type="text/javascript">
    $('555').childNodes[0].style.color = '#ccc';
</script>

解决方案

参见糟糕实践一的解决方案

 糟糕实践三：依赖特定的节点类型

项目中依赖的基础库是jQuery，jq提供了非常强大的选择器，很常见的就是可以通过节点类型进行选择，比如下面代码。如果你那么写的话，接手你代码的兄弟估计会恨死你。

<h2>依赖节点类型</h2>
<div id="666">
    <ul></ul>
</div>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript">
    $('#666 ul').html('<li>昵称：程序猿小卡</li><li>爱好：漫画</li>');
</script>

问题很明显，$('#666 ul')选中了id为666的节点下所有节点类型为UL的子节点、孙节点、曾孙节点。。。我就掉这个坑里了，但是需要在上面加多个下拉列表，于是毫不犹豫地采用UL来模拟，大致如下。运行的结果绝对让你抓狂。

<h2>依赖节点类型</h2>
<div id="777">
    <ul></ul>
    <ul>
        <li>选项一</li>
        <li>选项二</li>
        <li>选项三</li>
    </ul>
</div>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript">
    $('#777 ul').html('<li>昵称：程序猿小卡</li><li>爱好：漫画</li>');
</script>

 解决方案

参见糟糕实践一的解决方案。

 糟糕实践四：不合理利用元素选择器声明样式

跟上面的例子其实很类似，还是用上面的标签来说明问题。同事的愿望很朴素，就是希望将ul节点下的文本都设置为红色而已。

<style type="text/css">
    ul{
        color: red;
    }
</style>
<h2>依赖节点类型</h2>
<div id="666">
    <ul></ul>
</div>

然后，我往里面查了另一个ul元素来模拟下拉列表，悲剧了，原先声明的样式伤及无辜。。

<h2>依赖节点类型</h2>
<div id="777">
    <ul></ul>
    <ul>
        <li>选项一</li>
        <li>选项二</li>
        <li>选项三</li>
    </ul>
</div>

 解决方案

尽可能地避免通过元素选择器来声明样式（reset css的除外），如果非用不可，那么尽可能地将杀伤范围限制得足够小，如在某个特定的id、class内部用元素选择器，就像下面这样这样。

注意：尽管这样做看上去安全了些，但还是有不小的隐患，千万小心

.restrict_style ul{ color: red; } // 通过外层容器，限制选择器的

糟糕实践五：节点查询依赖于样式类名

在一个页面中，id是唯一的，给太多的节点加上id，很容易造成节点id的冲突。常用的推荐解决方案是，给最外层的容器节点加上id，而对于子节点，则加上相应的class，以此达到方便查询、避免冲突的目的。下面这样的代码相信大家不陌生，包括不少开源组件都是这么个思路。

<h2>节点查询依赖于类名</h2>
<div id="888">
    <span class="nick">昵称：程序猿小卡</span>
    <span class="hobby">爱好：动漫</span>
</div>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript">
    $('#888 .nick').css('color', 'green');
    $('#888 .hobby').css('color', 'orange');
</script>

上面的代码看上去没什么问题，那究竟为什么说它糟糕呢？因为：1、不利于样式重构 2、修改容易导致bug

假设某个晴朗的早晨，产品同学找到你说，这里这里的样式需要改版，你稍微一评估，自信满满地说：没问题，很简单。于是你就开工了，既然是改版，肯定是大动刀了。过了一会，你的眼球突然被<span class="nick"></span>这个标签吸引了：好好的炎黄子孙class名干嘛起得这样洋里洋气的，太装了吧（很不恰当的例子哈，只是为了说明因某些原因需要修改类名）。于是果断将“nick”改成了“nicheng”，多通俗易懂啊。

于是，悲剧了，在本文的例子里，把“nick”改成“nicheng”，只是会导致样式稍微有点不正常，但严重的时候脚本错误都有可能

<h2>节点查询依赖于类名</h2>
<div id="999">
    <span class="nicheng">昵称：程序猿小卡</span>
    <span class="aihao">爱好：动漫</span>
</div>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript">
    $('#999 .nick').css('color', 'green');  // 节点取不到了
    $('#999 .hobby').css('color', 'orange');

    $('#999 .nick')[0].innerHTML = '程序猿小卡'; /// 出错了，因为$('#999 .nick')[0]为undefined
</script>

解决思路

大家都推崇的开发方式（外层id，内层class），是不是就不要用了呢？当然不是，只不过可以稍微调整下：

1、外层容器用id

2、子节点用class，但class前需要加上“js-”等特殊前缀，标识该样式为js代码里需要用到的。对这样的class不要随便动它，如果需要修改，请先搜索下整个工程目录，确保你的修改不会导致bug。

简单修改下上面的例子，好了，nick、hobby，随你修改了~

<h2>节点查询不依赖于样式类名</h2>
<div id="1010">
    <span class="js-nick nick">昵称：程序猿小卡</span>
    <span class="js-hobby aihao">爱好：动漫</span>
</div>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript">
    $('#999 .js-nick').css('color', 'green');  // 节点取不到了
    $('#999 .js-hobby').css('color', 'orange');

    $('#999 .js-nick')[0].innerHTML = '程序猿小卡'; /// 出错了，因为$('#999 .nick')[0]为undefined
</script>

更多糟糕实践

待补充