スタイルのレビューをお持ちですか?これを行う人はほとんどいませんが、実際、開発者はそのような態度を持つべきであり、特に異なるチームの複数人が開発する場合、これは特に重要です。
この記事では 2 つの点について説明します。1 つはスタイルをレビューする必要がある理由、もう 1 つはレビュー ツールをビルド プロセス全体に統合する方法 (CSS に適用されますが、Sass にも適用されます) です。
コードレビューとは、コードがプログラミング仕様に準拠しているかどうかをチェックし、コードのエラーを見つけるプロセスです。比喩を作成する場合は、プログラミング言語のスペルチェッカーツールです。コード レビューは、独立した開発者がコードをより適切に保守するのに役立ちますが、そのより大きな機能は、チームがコードを保守するのを支援することです。
スタイルを見直す理由はたくさんあります。たとえば、コードの一貫性を維持できる、コード内のエラーを解決できる、冗長なコードを減らすことができるなどです。
いくつかの例を見てみましょう:
.no-space-after-colon { display:block;} ⬆.no-semicolon { position: relative ⬅}
コード レビュー ツールは、上記のコードの不規則性を効果的に指摘できます。レビュー ツールでコードをどのように記述するかを指定する必要はありませんが、コードの一貫性を維持するのに役立ちます。また、グループ開発に慣れていないので、上記のコードを見たらイライラしてしまいます。
.invalid-hex { color: #FFF00G;} ⬆
コード レビュー ツールは、無効な色の値を指摘し、型エラーをスローすることもあります。このエラーを見逃すと、多くの場合、ページ上で重大な視覚的エラーが発生する可能性があります。
.unnecessary-prefixes { -webkit-border-radius: 5px; -moz-border-radius: 5px; border-radius: 5px;}
ブラウザのアップグレードに伴い、一部の CSS3 プロパティのブラウザ プレフィックスは意味を失いました。コード レビュー ツールは、これらの無意味なプレフィックスを指摘することができ、Autoprefixer と組み合わせるとさらに効果的になります。
うわースタイルの重複はよくある間違いです。上記のコードに関する限り、ここでの遷移値は不透明度ですか、それとも背景色ですか?明らかに、背景色が不透明度を置き換えます。
コードレビューはとても役に立ちますか?これだけでは印象に残らない場合は、読み続けてください。
stylelint は、拡張が簡単で、最新の CSS 構文をサポートし、CSS に似た構文も理解できる Javascript ベースのコード レビュー ツールです。また、JavaScript をベースとしているため、Ruby で開発された scss-lint よりも高速です。
stylelint は、開発者が統一されたコード標準を実装し、スタイル エラーを回避するのに役立つ強力で最新の CSS レビュー ツールです。
stylelint は PostCSS を利用しているため、SCSS などの PostCSS によって解析された構文も理解できます。
PostCSS は、JS を使用してスタイルを解析するプラグインのコレクションであり、CSS コードをレビューし、CSS 構文 (変数やミックスイン マクロなど) を拡張するために使用できます。また、将来の CSS 構文、インライン イメージなどもサポートします。 。
PostCSS の哲学は、1 つのことに集中して徹底的に実行することです。現在 200 を超えるプラグインがあり、それらはすべて JavaScript に基づいて記述されているため、非常に高速に実行されます。
PostCSS と stylelint は次に紹介するコードレビューツールです。
この記事では、よりわかりやすく簡潔な構成から始める方法を説明します。個人的には、公式設定ファイルよりも柔軟だと思います:
.duplicate-rule { display: block; transition: opacity .2s; color: #444; background-color: #eee; transition: background-color .4s; ⬅}
CSSの見直し方
"rules": { "block-no-empty": true, "color-no-invalid-hex": true, "declaration-colon-space-after": "always", "declaration-colon-space-before": "never", "function-comma-space-after": "always", "function-url-quotes": "double", "media-feature-colon-space-after": "always", "media-feature-colon-space-before": "never", "media-feature-name-no-vendor-prefix": true, "max-empty-lines": 5, "number-leading-zero": "never", "number-no-trailing-zeros": true, "property-no-vendor-prefix": true, "rule-no-duplicate-properties": true, "declaration-block-no-single-line": true, "rule-trailing-semicolon": "always", "selector-list-comma-space-before": "never", "selector-list-comma-newline-after": "always", "selector-no-id": true, "string-quotes": "double", "value-no-vendor-prefix": true}
npm install gulp-postcss postcss-reporter stylelint --save-dev
さらに驚くべきことは、Sass をサポートするために同時にコードを少し変更するだけで済むということです。
Sass をレビューする方法
/** * Linting CSS stylesheets with Stylelint * http://www.creativenightly.com/2016/02/How-to-lint-your-css-with-stylelint/ */var gulp = require('gulp');var postcss = require('gulp-postcss');var reporter = require('postcss-reporter');var stylelint = require('stylelint');gulp.task("css-lint", function() { // Stylelint config rules var stylelintConfig = { "rules": { "block-no-empty": true, "color-no-invalid-hex": true, "declaration-colon-space-after": "always", "declaration-colon-space-before": "never", "function-comma-space-after": "always", "function-url-quotes": "double", "media-feature-colon-space-after": "always", "media-feature-colon-space-before": "never", "media-feature-name-no-vendor-prefix": true, "max-empty-lines": 5, "number-leading-zero": "never", "number-no-trailing-zeros": true, "property-no-vendor-prefix": true, "rule-no-duplicate-properties": true, "declaration-block-no-single-line": true, "rule-trailing-semicolon": "always", "selector-list-comma-space-before": "never", "selector-list-comma-newline-after": "always", "selector-no-id": true, "string-quotes": "double", "value-no-vendor-prefix": true } } var processors = [ stylelint(stylelintConfig), // Pretty reporting config reporter({ clearMessages: true, throwError: true }) ]; return gulp.src( // Stylesheet source: ['app/assets/css/**/*.css', // Ignore linting vendor assets: // (Useful if you have bower components) '!app/assets/css/vendor/**/*.css'] ) .pipe(postcss(processors));});
npm install postcss-scss --save-dev
//[...] return gulp.src( ['app/assets/css/**/*.css', '!app/assets/css/vendor/**/*.css'] ) .pipe(postcss(processors), {syntax: syntax_scss}); ⬅});
npm install gulp-postcss postcss-reporter stylelint postcss-scss --save-dev
和 PostCSS 一样,Stylelint 也可以通过插件进行扩展。接下来让我们通过一些实例学习如何使用审查工具改善代码的可读性和可维护性。
话说有个产品经理新接了个 web app 的活,项目正处于紧张的开发中,为了减少一些开发时间,他决定增加一个特性来替代之前的一揽子方案,这个特性是这样的:给组件本身添加一个鼠标悬停时的 box-shadow 效果,同时给组件的内部的链接增加一个鼠标悬停样式。
下面是这个产品经理增加的代码段:
.component { position: relative; //[...] &:hover { ⬅ box-shadow: 1px 1px 5px 0px rgba(0,0,0,0.75); .component__child { ⬅ ul { ⬅ li { ⬅ a { ⬅ &:hover { ⬅ text-decoration: underline; } } } } } }}
真是惨不忍睹!
选择器嵌套是 Sass 最容易被误用的特性,合理使用它可以提高开发效率,滥用则会毁掉整个项目。嵌套往往是由偷懒引起的,这些代码往往难以阅读。上面的 &:hover{...} 的嵌套层级太深,很容易混淆其他开发者对这段代码的理解。最重要的是,这段嵌套在这里完全是没有必要的。
这就是上面的嵌套代码编译生成的 CSS:
.component:hover .component_child ul li a:hover {}/* What the heck is this?! */
如果后续接手项目的开发者想要覆盖这段级联样式,那真是大工程。所以有一点值得牢记,那就是除非你非常确定嵌套是必要的,否则不要使用它。
幸运的是,我们有插件来阻止这种情况的发生!我们可以安装 stylelint-statement-max-nesting-depth 插件,设置最大嵌套层级来避免过渡嵌套的现象:
npm install stylelint-statement-max-nesting-depth --save-dev
在 gulp 的排位置文件中增加 scss-lint 相关的任务信息:
gulp.task("scss-lint", function() { var stylelintConfig = { "plugins": [ "stylelint-statement-max-nesting-depth" ], "rules": { //[...] "statement-max-nesting-depth": [3, { countAtRules: false }], } } //[..]});
为了增强团队的共建意识,我在这里将 limit 设置为了 3 。由于有嵌套层级的限制,所以产品经理就会来自 stylelint 的重构提示。产品经理没怎么细想,就改成了下面这样:
.component:hover { box-shadow: 1px 1px 5px 0px rgba(0, 0, 0, 0.75); .component__child { ul { li { a:hover { text-decoration: underline; } } } } }
这个重构之后的版本看起来可读性好多了,但仍然有不少缺陷。事实上,上面代码中的嵌套是完全没有必要的。stylelint 可以检测出这一点,并会强制产品经理重新思考样式代码。
.component:hover { box-shadow: 1px 1px 5px 0px rgba(0, 0, 0, 0.75);}.component__child { a:hover { text-decoration: underline; }}
现在,代码更加健壮了!stylelint 已经接受了代码,不会再提出异议了。虽然上面的代码没有问题,但我们其实可以做的更好。如果你希望严格要求团队的每一个成员,那么可以禁用嵌套,这会让团队成员,包括产品经理,更加严谨地编写代码。
.component:hover { box-shadow: 1px 1px 5px 0px rgba(0, 0, 0, 0.75);}.component__link:hover { text-decoration: underline;}
通过以上介绍和实战演练,希望我已经说服了你:样式审查是非常值得投入的一项流程。代码审查应该成为我们的朋友,只需投入一点时间,就可以收获代码整体的可读性、可维护性。
本文根据 @Scotty Vernon 的《 How to lint your Sass/CSS properly with Stylelint 》所译,整个译文带有我们自己的理解与思想,如果译得不好或有不对之处还请同行朋友指点。如需转载此译文,需注明英文出处: http://www.creativenightly.com/2016/02/How-to-lint-your-css-with-stylelint/ 。
前端开发者,关注性能优化和动效设计,活跃于 Github @pinggod 、微博@ping4god 和博客 pinggod.com ,替身众多。如果你沉醉于 Kairosoft、午时三刻工作室的游戏,请来和我做朋友:)。