如何规范CSS命名?更好的协同开发!

2021-07-23 22:06:58 浏览数 (2552)

很多小伙伴可能都以为前端开发工程师需要自己写所有的页面文件。但实际上前端开发工程师在进入岗位后需要干的第一件事情就是查看前人写的页面文件(特别是css和js)。原因很简单,css和js这些都是可以复用的(尤其是css),而且对于一个网站而言,统一的风格很重要,所以会出现多个页面共用一个css的现象。介绍这些内容主要是为了引出接下来要讨论的内容?如何协同开发页面?实际上应该换种说法:如何统一开发思想?要统一开发思想需要先干的一件事,就是统一代码规范,接下来小编会分成三篇文章介绍前端编码规范,本篇文章要介绍的是:css规范。

命名规范

我们说过,我们最终的目的是协同开发,所以就要让我们的代码让别人看得懂。所以在css命名上需要有一定的规范,不同公司都有不同的规范,但这些规范大多都有相同的特点:

  1. 类名不使用魔法类名,也就是说,你的类名不能随便起,应当具有一定意义(比如a,b这种类名就是不负责任的一种起名方式)。
  2. 如果可以,请不要使用拼音作为命名,因为阅读代码的人不一定会懂拼音,这不利于维护
  3. 如果可以,类名尽量简写(前提是能让人看得懂,也就是说在2的基础上简写。
  4. 类名的命名时如果涉及多个单词组成的长名称或者词组,需要进行连字符进行连接,请使用中划线(-),因为下划线是js中经常使用到的,使用中划线避免冲突。
  5. 不要随便使用id选择器(不然会出现命名荒),id选择器在页面中是唯一的,不可复用,而且id的优先级比较高,所以在调试上会比较麻烦。所以尽量按需使用。
  6. 为选择器添加状态前缀(或者直接以一个状态命名一个选择器)这样可以更有语义化,比如某个标签被选中激活了,可以使用active作为一个激活情况的css来应用。
  7. css对大小写不敏感(不是绝对的,如果与HTML文档一起工作,class和id就对大小写敏感,所以,请统一使用小写),但并不意味着你可以随便采用大小写混合,最好的方式是统一用大写或者小写,就个人经验而言,小写字母更易阅读。

书写顺序

  • css是有顺序的,后面写的样式在优先级相同的情况下会覆盖掉前面的样式,所以请注意你的书写顺序!
  • 我们一般写css的时候要按照一定的顺序有规律的写css代码,这样会提高代码的可阅读性。一种经典的css属性书写顺序是这样的:
  1. 位置属性(position, top, right, z-index, display, float等)
  2. 大小(width, height, padding, margin)
  3. 文字系列(font, line-height, letter-spacing, color- text-align等)
  4. 背景(background, border等)
  5. 其他(animation, transition等)

  • 另外,在一些简写中也要求属性按一定顺序排列,比如当简写background属性时,属性值的顺序为:
  1. background-color
  2. background-image
  3. background-repeat
  4. background-attachment
  5. background-position

其他代码优化

  • 在可以使用简写的情况下请尽量使用简写,这样能精简代码便于阅读。
  • 如果有小数点前是0的话,可以去掉小数点。(但是小编还是以为留着小数点会更有阅读性)。
  • 如果使用16进制颜色代码,可以缩写的话尽量缩写。(但是大多数情况不一定能缩写,所以不缩写也不会有太大的阅读问题)。
  • 注释很重要,要明白你写的代码最后不只是你要看的,好的注释可以让你的同事更好理解你的代码,也能避免同事间的冲突(试想一下,你看到的写的想屎一样的代码来自你的一个不是很待见的同事,你会给他好脸色吗?)。
  • 不要使用​!important​,它是样式优先级最高的意思,如果使用他会让本来就不好调试的css代码更加混乱,这个命令通常是在调试的时候使用的,尽量不要写进生产代码。

如果对你的代码是否符合规范还有疑惑,一些开发工具提供代码检查功能(没错我说的就是jetbrain公司的产品,他们家的webstorm,PHPstorm,还有可以兼职编写前端页面的idea,pycharm等都有代码检查功能,可以检查css是否符合规范)。

小结

符合CSS规范虽然并不能让你的代码渲染得更快,但是它可以让你和你的同事进行协同办公,这样可以提高个人和整个团队的工作效率,也能减少团队之间的摩擦。当下的软件开发不像以前可以单打独斗,更多的情况下都是一个团队在为之奋斗。所以学号css规范相当重要!更多代码规范可以继续阅读W3Cschool之后或之前的文章。