“代码质量”这个术语对于程序员来说并不陌生。毕竟，每个开发人员都知道，代码只是能工作是不够的。它还应该具备其他要素：它应该是可读的，良好的格式和一致性。它也应该符合一些标准的量化指标。不过这些在写CSS时，经常被忽略。我们可以花很多时间讨论为什么会发生这种情况，但重要的是，CSS编码是和JavaScript，PHP等一样，我们要关注我们写代码的方式。否则，可能会导致很多复杂的问题。
在本文中，我们将探讨我们如何能够利用PostCSS帮助我们，保持我们的CSS代码质量更高。首先，找出“好CSS代码”的含义。有几件事情需要注意的：
1、代码应该是一致的风格-你可以选择如何命名类名，如何换行或如何列出需要的属性，但你应该保持所有样式的方式相同。一贯的风格提高可读性，使代码更容易理解。
2、代码应该遵守一些量化标准-有定量的度量，我们保证代码可以测量并保持在基本标准以上，比如页面上使用了统一的颜色表示方式，选择器的最大层数。
3、应该避免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或标签。
这两个插件可用于代码分析。下面是几个例子：
1、保证在一个线程的使用的实体的特征，大小和数量。
2、确保所有的选择器都是符合编码风格的。
3、确保媒体查询的一致性。
这些只是一些想法。更实际的做法是先使用之前的插件，再回到这两个插件，看是否可以提供更多有用的信息。
结束语
代码测试和分析仅仅PostCSS使用方式之一，其本身可以有很多功能可以添加到你的开发过程，可以节省开发人员的时间和麻烦。即使在其他编程领域，CSS仍然经常被忽视是很觉。但我相信，在配置PostCSS和这几个插件是使您的开发更容易，更可靠的一步。
原文标题：Improving the Quality of Your CSS with PostCSS
原文件链接：http://www.sitepoint.com/improving-the-quality-of-your-css-with-postcss/