[翻译]用PostCSS改善你的CSS代码质量

“代码质量”这个术语对于程序员来讲并不陌生。毕竟，每一个开发人员都知道，代码只是能工做是不够的。它还应该具有其余要素：它应该是可读的，良好的格式和一致性。它也应该符合一些标准的量化指标。不过这些在写CSS时，常常被忽略。咱们能够花不少时间讨论为何会发生这种状况，但重要的是，CSS编码是和JavaScript，PHP等同样，咱们要关注咱们写代码的方式。不然，可能会致使不少复杂的问题。
在本文中，咱们将探讨咱们如何可以利用PostCSS帮助咱们，保持咱们的CSS代码质量更高。首先，找出“好CSS代码”的含义。有几件事情须要注意的：

• 一、代码应该是一致的风格-你能够选择如何命名类名，如何换行或如何列出须要的属性，但你应该保持全部样式的方式相同。一向的风格提升可读性，使代码更容易理解。

• 二、代码应该遵照一些量化标准-有定量的度量，咱们保证代码能够测量并保持在基本标准以上，好比页面上使用了统一的颜色表示方式，选择器的最大层数。

• 三、应该避免HACK-例如，在某些状况下，!important有时看起来像可行的解决方案，但一般会使代码更复杂。

这不是一个完整的列表，但咱们必须关注上述问题。虽然是显而易见的，但若是在一个不少人参与的项目里，人们技能各不相同,以上问题就很容易被忽略。咱们但愿有一个工具，能够帮助咱们经过代码分析工具自动实施这些标准。

怎样使用PostCSS

在这篇文章中，咱们重点介绍几个PostCSS插件，能够帮助咱们提升CSS代码质量。
在开始以前，先使用gulp工具创建一个环境。首先，建立一个新的文件夹，并用npm初始化。而后，安装gulp的PostCSS插件reporter plugin，写一个任务查看PostCSS插件的输出。
具体方法是切换到新建立的文件夹并运行：

npm i gulp gulp-postcss postcss-reporter --save-dev

在建立一个空的style.css文件和gulpfile.js包含如下内容以后：

var gulp = require('gulp');
gulp.task('analyze-css', function () {
  var postcss = require('gulp-postcss');
  var reporter = require('postcss-reporter');

  return gulp.src('style.css')
    .pipe(postcss([ 
      reporter()
    ]));});

建立扫描style.css内容的任务,并经过一系列PostCSS插件运行它。在命令行下你已经能够运行gulp analyze-css，postcss-reporter只是一个日志插件。让咱们添加一个测试插件。

Stylelint

如今大多数语言都有检测工具，CSS也不例外。Stylelint容许您按照一组预约义的规则验证你的CSS代码，它能够检查代码格式的一致性，规则，单位或指令的使用状况，以及潜在的错误（如颜色值不正确）。它容许自定义检查规则 -它自己也有一些基本的检测，好比，确保选择器和下面的大括号有一个空格，引号成对使用。还有其它一些规则。下面是几个例子：

• property-blacklist和unit-blacklist容许您指定不使用的属性和单位的列表。
• property-no-vendor-prefix 警告您关于使用浏览器前缀，不要求他们根据 Can I use.的数据检测属性。
• declaration-no-important 不容许使用!important指令。
• selector-max-specificity 限制选择器的最大层级。

Stylelint默认状况下禁用了全部附带的规则，因此但愿你来配置本身的规则。配置可能花点时间。或者，也能够扩展标准配置，如stylelint-标准配置，并用本身的规则对它进行扩展。
设置stylelint一个标准的规则集：

npm i stylelint stylelint-config-standard --save-dev

对gulpfile文件添加代码，以使用新的插件：

var gulp = require('gulp');
gulp.task('analyze-css', function () {
  var postcss = require('gulp-postcss');
  var stylelint = require('stylelint');
  var reporter = require('postcss-reporter');

  return gulp.src('style.css')
    .pipe(postcss([
      stylelint(), 
      reporter()
    ]));});

Stylelint规则能够内嵌在gulpfile文件中，最后在一个单独的文件定义。在项目文件夹中建立.stylelintrc文件，并添加以下内容：

{"extends": "stylelint-config-standard"}

这将告诉stylelint，咱们本身的规则集是基于stylelint的标准配置。如今更新style.css文件而且测试插件查测CSS片段的状况：

.title,.content{ 
  background: #FFFFFF; 
  font-size:0.9em;
  margin: 0;
}

运行gulp analyze-css 产生下面的报告：

style.css
1:7    Expected newline after "," (selector-list-comma-newline-after) [stylelint]
1:15   Expected single space before "{" (block-opening-brace-space-before) [stylelint]
1:17   Expected newline after "{" of a multi-line block (block-opening-brace-newline-after) [stylelint]
1:17   Unexpected whitespace at end of line (no-eol-whitespace) [stylelint]
2:5    Expected indentation of 2 spaces (indentation) [stylelint]
2:17   Expected "#FFFFFF" to be "#ffffff" (color-hex-case) [stylelint]
2:17   Expected "#FFFFFF" to be "#FFF" (color-hex-length) [stylelint]
2:25   Expected newline after ";" in a multi-line rule (declaration-block-semicolon-newline-after) [stylelint]
2:25   Unexpected whitespace at end of line (no-eol-whitespace) [stylelint]
3:5    Expected indentation of 2 spaces (indentation) [stylelint]
3:15   Expected single space after ":" with a single-line value (declaration-colon-space-after) [stylelint]
4:4    Unexpected whitespace at end of line (no-eol-whitespace) [stylelint]
5:4    Unexpected whitespace at end of line (no-eol-whitespace) [stylelint]
6:5    Expected indentation of 2 spaces (indentation) [stylelint]
7:1    Unexpected missing newline at end of file (no-missing-eof-newline) [stylelint]

使用这个插件能够帮助编写良好的规范的CSS。经过自定义规则列表和覆盖标准配置的那些不用的配置。您能够把这些规则做为项目和团队的规则。若是标准规则，没有符合要求，你也能够本身写一个。

Do I Use

在写css时要适配多个浏览器是一件痛苦的事。Do I Use 是一个帮助你写出适配多个浏览器CSS的插件。首先定义哪些浏览器是要支持的。以后，当您运行的插件，它会经过caniuse.com的数据库来检查你的代码。若是一些代码不被支持，则提示错误。
使用至关简单的。安装：

npm i doiuse --save-dev

更新gulpfile：

return gulp.src('style.css')
  .pipe(postcss([
    doiuse({
      browsers: ['ie >= 9', 'last 2 versions'],
    }),
    reporter()]));

此配置定义要支持浏览器的最新2个主要版本，IE9及以上。

为了演示，将运行插件来检测一些新CSS属性，如：网格布局模功能。

body {
  display: grid;
  grid-columns: 200px 1% 1fr;
  grid-rows: auto 15px auto 15px auto;}

下面是doiuse给出的报告：

style.css
11:2 CSS3 Multiple column layout not supported by: IE (9), Firefox (43,44),
 Chrome (48,49), Safari (8,9), Opera (34,35), iOS Safari (8.1-8.4,9.0-9.2) 
(multicolumn) [doiuse]

在写CSS的时候，浏览器不能很好的支持CSS网格模块。可是，do i use工具能够帮助咱们追踪浏览器的支持状况！

Immutable CSS

如今样式表中重写CSS规则，会带来错误和复杂性。即便使用现代调试工具，弄清楚那里的样式被重写或为何，有时也是一项挑战。这就是为何添加修饰符给选择器比重写样式更好的缘由。immutable CSS插件对样式重写发出警告。
有两种操做模式。默认状况下，若是在不一样的文件重写样式，只警告你。当多个文件合并成单一的文件，它会利用源文件地址，找出其中哪里重写的样式的。这意味着它能够与Sass或postcss-impot插件很好的兼容。若是你想更严格，能够启用严格模式，在一个单一的文件重写样式也会发生警告。
这里有一个简单的示例。先安装插件：

npm i immutable-css --save-dev

并在gulpfile里启用插件严格模式：

return gulp.src('style.css')
  .pipe(postcss([
    immutableCss({
      strict: true
    }),
    reporter()
  ]))

而后准备不友好的CSS片段：

.title {
  color: blue;
  font-weight: bold;}

.title {
  color: green;}

.article .title {
  font-size: 1.2em;}

下面是该插件的报告，.title伪类已突变：

.title was mutated 3 times[line 1, col 1]: /Users/pavels/Documents/projects/sandbox/postcss/style.css
[line 6, col 1]: /Users/pavels/Documents/projects/sandbox/postcss/style.css
[line 10, col 1]: /Users/pavels/Documents/projects/sandbox/postcss/style.css

想了解更多这个插件的信息，能够访问 官网.。

CSS Stats and List Selectors

咱们来看一下最后两个插件 CSS stats和list selectors。他们和上面提到的检查类插件有点不一样：它们的目的不是指出问题，而是提供了自定义分析数据。
CSS stats提供了基本的样式信息：多少规则，选择器或使用的声明，它们是什么，指出一些特殊选择器，或代码中font-size出现的次数。这只是一个简单的生成报告中包含的信息样本。更详细的说明上它的页面GitHub的。你也能够访问cssstats.com看一些利用插件生成数据报告的例子。
List selectors 插件更简单，它侧重于提取的样式表中使用选择器的列表，并经过类别将它们分组 - 类选择器，属性，ID或标签。

这两个插件可用于代码分析。下面是几个例子：

• 一、保证在一个线程的使用的实体的特征，大小和数量。

• 二、确保全部的选择器都是符合编码风格的。

• 三、确保媒体查询的一致性。

这些只是一些想法。更实际的作法是先使用以前的插件，再回到这两个插件，看是否能够提供更多有用的信息。
结束语
代码测试和分析仅仅PostCSS使用方式之一，其自己能够有不少功能能够添加到你的开发过程，能够节省开发人员的时间和麻烦。即便在其余编程领域，CSS仍然常常被忽视是很觉。但我相信，在配置PostCSS和这几个插件是使您的开发更容易，更可靠的一步。

原文标题：Improving the Quality of Your CSS with PostCSS
原文件连接：http://www.sitepoint.com/improving-the-quality-of-your-css-with-postcss/