关于前端命名规范的一些心得

一名刚入行或者入行没多久的前端，最开始接触到的问题可能就是规范了。而规范里，又数命名最重要，至少我个人是这么认为的。

在企业中，一个项目往往都需要由一个团队来完成，在多人合作中，个性往往会成为阻碍。当然，这里我并不是想要否定个性在开发中的优势和作用，但个性过于强烈，很多时候会让合作变得难以成功，至少我们的命名不需要太有个性。

然而，如果你能力足够且足够主动，完全可以让别人“强行”接受自己的个性，自己定义规范，让团队遵守，即使你还是一名刚入职的小员工。当然，前提是你能够说服你的领导和团队。

而在进入正题之前，我或者需要重申一个问题：我是一名入行没多久的前端工作者。而写这篇文章的目的是什么？或者是想让大家都主动一点吧，新人有想法不要害怕提出。

好了，废话就不多说了。下面分享一下我在工作中收获到的一些关于前端命名规范的心得吧。

命名规范主要包括css命名、js命名和图片命名，首先来讲讲css命名。

css命名

1、使用BEM命名，以下划线区分：模块_元素_修饰符。

如：

这样，我们就能比较清晰的知道这些结构的层级关系了。不过，命名不宜过长，模块_元素_修饰符这三层就足够了，太长会影响可读性，如果还需要继续嵌套的话，跟外层一样，也是从模块到模块_元素_修饰符，之后用一层的后代选择器将他们连接起来。

如:

虽然说后代选择器的性能不如子选择器，但这里用子选择器会使代码显得更加臃肿，可读性和维护的便易性都会大打折扣，所以最后我选择了这样的仅有一层的后代选择器。而且事实上，这种使用方式与子选择器的性能消耗相差不会太大，在可以接受范围内。

2、以功能区分模块去命名。

为了提高复用性，减少代码冗余，尽量以功能区分模块这种方式去命名，需要进一步区分的再加一个class。

如：

JS命名

js命名比较简单，现在大部分使用的是小驼峰和下划线命名。

变量、函数用小驼峰，如：getParams

私有变量开头加下划线，如：_this

这样看起来整洁干净，可读性强。

图片命名

在项目中，图片的命名同样讲究，我的做法是结合小驼峰和下划线，以项目名称_图片名称_图片作用这样的格式去命名。

如：hotelProject_blueArrow_icon

在上述例子中可以看到，blueArrow就使用了小驼峰的命名方法，因为一个项目中可以存在很多arrow，所以我们需要为它添加特征以更好地区分开这些图片。

总结

命名格式固然重要，但命名中更重要的一点莫过于语义化，一段有语义的代码的可读性是远远高于没有语义的代码。在实际工作中，无论是团队合作还是个人的后续维护，如果没有好的命名规范，那你的工作将变得十分混乱。