切图崽的自我修养－规范CSS元素命名-白红宇

切图崽的自我修养－规范CSS元素命名

阅读量：5950 次

发布时间：2019-06-19

本文共 2174 字，大约阅读时间需要 7 分钟。

前言

为什么我刚才写的样式乱了？！

如何给变量，文件命名是程序员的老大难问题。命名为什么会这么难，因为它太重要了。可以这么说，准确的命名可以提高代码的可读性，让人容易理解，方便调试，也给以后修改和维护你的代码的人带来方便。

如何给元素命名

而在css中，如何给元素命名同样是一门艺术。我们先来看看css中对常用的组件的命名：

head

foot

list

嗯，目前为止很不错，这很简单，这很语义化。如果再复杂一点，比如我要一个下拉菜单，你可能会想到：

dropMenu［驼峰命名］

drop-menu/drop_menu[匈牙利命名]

没错，命名足够解释了它 特点是什么/有什么＋本身是什么。

好，那我们接下来看看这段代码：

这是一个表示时间的列表，用timeList命名非常合适。等会，现在需求好像变了，产品姐姐刚才凑过来说要把时间列表的最后一条数据高亮显示，那我们就得把timeList的最后一个li挂上一个class，用来做样式的调整，才能满足需求。OK现在变成：

然后css中如是写：

.timeList .last{...}

很简单 ~~父元素＋嵌套子元素~~ 的命名方式轻松搞定，但这样真的好吗？

NO! 一点都不好！

我们来看看这样命名存在哪些问题：

首先last这个命名本身非常让人疑惑，因为最后一个这个特性，不管你挂的是什么class，我们本来都可以从DOM上看出来的与其命名为last，不如命名为highlight，表明它的特点高亮

其次last这个命名容易引起代码冲突

因为.last这个命名很容易出现。在网站的开发过程中，会存在并行开发的情况，css不止你在写，你的同事可能也在写。如果恰巧他写了一个全局的 .last，那么你这个样式很可能会因为你同事写的样式的叠加而产生问题。

你想了一会，改成了：

嗯，lastItem至少last好，但还是没有解决上述的两个问题，特性不明＋代码冲突风险。反正如果是我，就算写成：

.timeList .lastItem{...}

这种形式，我还是会担心有人写了.lastItem的全局样式导致我的代码样式会被覆盖。

所以，上述这种子元素嵌套 (我们叫做滥用子元素选择器) 的方式是 非常不可取的，即使你自己的代码写起来没有问题，一旦和别人的代码整合起来，很可能产生命名冲突。

所以，为了避免多人开发命名冲突的情况发生，css的样式命名最好和程序语言一样，遵循命名空间的原则。

命名空间

所谓命名空间，就是从属关系的一种表示方法。还是拿上述的例子来说，如果写成：

timeList下的LastItem，嗯，看出了从属关系，并且如此复杂的命名一般不会引起代码命名上的冲突，并且同时也简化了你的css，因为现在你的css可以这样写了：

.timeListLastItem{...}

css里不用嵌套在父元素选择器里了，因为这个子元素本身的命名就表示了，是在timeList这个父元素下的，也就是，从命名上就定义了自己的从属关系。

目前为止，这个命名已经可以打90分，离满分存在的差距在哪里?

如果一律采取驼峰命名，在从属关系的可读性上，稍微差了一点，来比较一下这两个命名的可读性：timeListLastItem 和 timeList-lastItem 明显采取驼峰＋匈牙利命名的方式可读性更强。

总结来说，用划线作为从属关系的分隔符，其实就是讲模块timeList视为了类，从属元素被看成了timeList的类属性。通过科学合理的命名上能直观的看出从属关系，降低代码冲突的风险。

所以如下两种命名方式，你选择哪一个呢？

结语

给元素命名从来不是一件简单的事情，但好的命名规范绝对可以减少使团队开发的潜在风险。虽然这种命名规范有时候会伴随着冗长的问题，但它所带来的好处绝对能掩盖这点瑕疵。至于担心命名长度的增加会影响css文件的大小从而会影响加载速度，我只能说同学，你的图片压缩过了吗？做了Sprite处理吗？那才是优化大头。

文章参考自：

转载地址：http://whsxx.baihongyu.com/

你可能感兴趣的文章