如何编写出可维护性强的Css

朴灿烈づ我的快乐病毒、 2022-09-04 02:52 218阅读 0赞

### 文章目录 ###

*  前言
 *  使用Sass（★）
 *  构建一个良好的文件结构（★）
 *   *  7-1模式（不是7减1，是7杠1）
     *   *  7个文件夹
         *  1个main.scss
     *  css分类方法
 *  规范的Css命名（★）
 *   *  BEM 命名
     *   *  注意点
     *  小写英文单词或组合命名
 *  样式优化（★）
 *   *  举例 line-height 如何优化
     *   *  方案1 声明时不带单位
         *  方案2 通过rem单位声明
     *  引出优化结论
 *  总结

--------------------

# 前言 #

在做项目的过程中，我发现尽管还原出来了原型图上的要求，但是css代码一直都是一大坨的扔在了`<style>`标签里面，让人根本没有想看的欲望。尤其是，最近的一次项目中突然加了个换肤的需求，看着自己之前写的css样式，甚至产生了跑路的想法。（游戏中的屎山也不过如此了吧 =.=）最后en是用js给重新替换了，也懒得写其他css代码了。

用我的话来说的话，我一直都在写**一次性代码**。所以，如何去提高自己代码的可维护性被提到了日程上，计划从Css开始，正好最近也在学Sass，先把“一次性代码”的臭习惯给改掉！

> 后面也会逐步思考怎样写出优质的js、vue代码（性能上、可维护性上等），本篇主要以开发可维护性强的css思路为主，代码部分可能偏少，希望能耐心看完给出建议！  
> 废话多也是建议，直接评论就行，咱皮厚 0.0

# 使用Sass（★） #

没学过Sass的前端人我觉得真的太难了，有了Sass能省下不少功夫，尤其是对于css代码的维护与编写上。

Sass是Css的一个预处理器，添加了一些很方便的特性，比如：  
变量、嵌套、导入、混合、函数、for循环、if判断、运算等等，可以看做把css向js靠拢了一点。

既然在写前端，难免会遇见各种各样的**颜色**啊，**字号**啊，**背景**啊这些很多需要**重复声明的属性**，而这些东西一旦改起来也是大海捞针一般，尤其是在写完项目过了很长时间之后。

而这时，一旦有了**变量**存在，一切烦恼都烟消云散了。我们只需要新建一个Sass文件，在里面放上一些**公共的样式**即可，需要的时候直接`@import`导入就能够使用我们在这个文件定义的变量了。

我们可以声明一个主题色，以及与其对应的各种按钮及文字颜色，当需要更改时，我们只需在主题文件（或颜色文件）中做些处理，做到**牵一发而动全身**。

> 写过Css的都知道变量的出现意味着什么，维护一个变量和维护一堆字符串肯定选变量

# 构建一个良好的文件结构（★） #

之前写css都是一个文件代码直接拉满，现在想想真的是初生牛犊不怕虎，完全没有考虑到**后期维护**或者**需求增加、变更**的可能性。  
换句话说，js、vue、node都模块化了，css还不往上面靠靠合适吗？

> vue3组合式Api不知道算不算模块化，感觉有些类似，但是核心思路都差不多，将功能相近代码或逻辑的抽出来，做到指哪打哪

## 7-1模式（不是7减1，是7杠1） ##

所谓7-1模式，就是将控制css代码相关的文件分成了七个文件夹，最后分块通过 `import` 引入到一个 `main.scss` 文件中，该文件放到根目录，以达到分工明确，逻辑清晰的目的。

### 7个文件夹 ###

*  **base**: 该文件中，放置所有的样板代码。这里说的样板文件，是指每次你开始一个新项目时，你要写的所有 CSS 代码。例如：排版规则，动画特效，公共工具(这里的公共工具是指如margin-right-large, text-center,…)等等。
 *  **components**: 该命名已经指明了其地位。此文件包含用于构建页面所需的组件，如：buttons、forms、swipers、popups等等。
 *  **layout**: 用于布局页面的不同部分。即：header、footer、navigation、section、grid等。
 *  **pages**: 有时候你可能写了一个页面，但要为其制定专属的样式，所以你把这种专属样式放置在 pages 文件夹中。
 *  **themes**: 如果你的 app 需要拥有不同的主题(黑暗主题，默认主题等等) ，把这些主题放置在该文件夹中。
 *  **abstracts**: 把你的所有函数，连同变量和mixins一起放置在这里面，简言之，就是放置所有的助手。
 *  **vendors**: 有什么 app 或项目不依赖于外部库吗？将那些不依赖与你自己写的样式文件防治站该文件夹中。你可能想在这里面添加 Font Awesome 文件、Bootstrap 等等类似文件。

### 1个main.scss ###

@import abstracts/variables;
    @import abstracts/functions;
    @import base/reset;
    @import base/typography;
    @import base/utilities;
    @import components/button;
    @import components/form;
    @import components/user-navigation;
    @import layout/header;
    @import layout/footer;

其中`@import`是Sass的语法格式，用于导入其他的scss文件，导入后就能直接使用在其内定义的变量了，不同于Css的什么时候用什么时候加载，Sass是直接加载。

> 代码块没有scss/sass格式的，凑合着用css吧  
> 上面的创建并非固定的，可以根据自身项目的大小自行调整文件结构

## css分类方法 ##

通过用途或性质将css分为几个大类

*  **公共型样式**
    
     *  对于**比较小的项目**，我们只引入一个css，这个css的样式即公共型样式，多用于：
        
         *  消除浏览器的默认样式（这方面网上有大佬写的现成的代码，不用自己写）
         *  统一调用背景图和清除浮动或其他需统一处理的长样式
         *  网站通用布局
         *  通用模块和其扩展
         *  元件和其扩展
         *  功能类样式
         *  皮肤类样式
 *  **特殊型样式**
    
     *  对某个**维护率较高**的栏目或者某个**与网站整体差异较大**的页面**独立引入**这样一个特殊型样式
 *  **皮肤型样式**
    
     *  说白了就是放颜色放背景的
 *  **重置和默认的css代码**
    
     *  消除默认样式和浏览器的差异，以减少后面的重复劳动
 *  **统一处理的css代码**
    
     *  统一调用背景图和清除浮动（指通用性较高的布局、模块、原件内的清楚）

我们可以按照上述规则建立目录，也能够实现上述7-1模式的效果

# 规范的Css命名（★） #

维护代码的前提是能看懂代码。见名知意已经提过无数次了，但是区别于其他语言，css的命名含义具有很高的重复性，像`.warp1`、`warp2`或是`nav-top`、`nav-left`这种很容易出现。但是自己写自己看还能稍微翻译翻译，但凡是换个人没冲过来揍我我就谢天谢地了。更别提还有偷懒没写注释的地方了。所以一个合理的命名，或者说一个统一的规范就显得尤为重要。

在此我搜了两个方案，供学习

> 并不确定是否为普及高的方案。不过真的进公司的话应该内部有自己的统一规范吧？

## BEM 命名 ##

命名: `块元素名称或元素名称` \+ `--` \+ `修饰符名称`  
简单来说就是 `组件_内部细节--这个组件或其内部细节长什么样子`

**块**  
通常指组件，例如一个`card`或者一个`form`

**元素**  
是“块”的一部分，它们是建造“块“的必需品。可以理解为一个组件中的细节部分，例如按钮、文本、数字等等，`.card_date`、`.form_author`

**修饰符**  
用于描述该块或元素。可以理解为你想实现的效果长什么样子。`.card_date--red`、`.post__btn--disabled`

### 注意点 ###

*  使用 BEM 时，命名只有 class 类名并且只使用 class 类名，没有 id ，没有标签，就只使用 class 类名。
 *  块/元素可以嵌套到其它块/元素中，但它们必须是**完全独立**的
    
     *  写出来的`card_btn--left`没人知道`left`是相对谁的，耦合度贼高，没有**独立**
 *  BEM会使HTML变的臃肿，还是看更注重什么吧，取决于个人，我认为是优大于劣。

## 小写英文单词或组合命名 ##

大致可以总结为：`外部结构` \+ `-` \+ `内部结构` \+ `-` \+ `目标功能描述`  
例如:`warp-nav-logo`、`nav-drop-list`

> 可能这种用的会多一点，但是起名字真的不好想，之前自己也用的这个，起着起着就发现自己文化不够了，一是想不出来叫什么，二是不确定自己写的到底属于哪部分

# 样式优化（★） #

其实这部分可能才是我最想表达的部分，不知道能看到这不…

想让Css代码能够具有比较强的可维护性，就必须要了解你写的**每个属性各自的特点**，以及**简写形式与不简写的差别**。无论是Sass还是Css，最最基础的语法其实是相同的，可能这么表达有点抽象，举个例子

假如我想设置一个行高，不论是Sass还是Css，我都得写上`line-height:16px`。但是假如我们想要对行高进行修改怎么办？改px呗。那一千个`line-height`怎么办？不怎么办，代码写的就是烂 =.=。

## 举例 line-height 如何优化 ##

有两种方案去优化

### 方案1 声明时不带单位 ###

当我们声明`line-height:1.5`时表示的意思是：使行高等于**字体的大小\*1.5**，假如这时候我们能够在全局设置好字体，那么我们就**只需要声明根元素的字体大小**，对于其他额外声明过字体大小的样式再做单独的修改即可。

### 方案2 通过rem单位声明 ###