CSS的SASS样式编程指南

随着越来越多的开发者使用SASS，我们有必要关注一下SASS的代码的个数问题。 我们可以从CSS（层叠样式表）的语法出发，来解释SASS语法的一些特别之处，毕竟，CSS样式指南是很常见的。

　　这篇文章主要介绍了我个人比较感兴趣的一些特性，也许能够让你从中受用，形成一套属于自己的SASS使用指南。
继续保持自己常用的CSS格式规则和样式指南

　　这篇文章着重讨论了关于SASS的一些内容，但是在此基础上，开发者应该保持自己已有并且良好的格式规则。如果你还没有发展出一套属于自己的格式规则，那么这里有一些样式指南的综述，应该可以帮你形成属于自己的CSS编写习惯。这里仅列出一些其中所包含的部分内容：

    1. 保持行缩进一致
    2. 保持冒号/大括号前后空格数的一致
    3. 保持一行一个选择器，一行一个规则
    4. 相关的属性尽量写在一起
    5. 对于类名命名规则由一个规划
    6. 避免使用CSS id选择器
    7. 等等

　　接下来我们就了解一下如何写出美观的SASS代码吧，以编写一个.weather类的属性为例：
　　首先列出@extend(s)
 

　　这样做能够使开发者保持一个清晰的思路，能够立刻知道这个类与其属性和其他类及其属性的关系，保持属性的一致和属性重用的清晰思路。
　　普通样式
 

　　这样做能够使开发者一眼看出@extend(s)和@include(s)的部署，便于自己以及其他开发者对代码的解读。你可能还会对是否区分自定义的@includes和公共来源的@includes在有些情况下做出决定（尤其是考虑到代码的可重用性和时效性）
　　选择器嵌套
 

　　在嵌套部分内，继续使用上述的样式规则。嵌套的部分永远都应该放在最后。
　　所有厂商前缀使用@mixins

　　厂商前缀（CSS前缀）具有非常强的时效性。 由于现代浏览器的更新，这些前缀的使用将越来越少。你可以通过更新mixins里的内容（或者在你mixin里用到的一些库将自动更新）去适应这些变化。 哪怕mixin只有短短一行，也没有关系。
但当某些厂商前缀的私有化非常严重时，这些前缀将非常难以标准化并且应用其他前缀或者无前缀的版本会得不偿失，我会选择放弃@mixin这些厂商前缀。比如像-webkit-line-clamp， -mscontent-zoom-chaining或者类似情形。
　　嵌套的层次不要超过3层
 

　　如果你的嵌套多余三次，你很有可能写出一个坑爹的（差劲的？）选择器。坑爹的原因不外乎这个选择器过于依赖HTML的架构（不稳定）， 过于详细（功能过于强大，没有弹性），或者是可重用性太差（不太可用）。同时，过多的嵌套层次容易导致代码处于晦涩难懂的境地。

　　如果有的时候与类相关的代码真的太多了，使得你不得已使用标签选择器。你可能需对于某个类要写的非常具体，以避免不必要的层叠。 甚至有可能的话，利用extend来使用CSS里一些可重用性的特性。
 

　　嵌套的代码不要超过50行

　　若果SASS里的嵌套多于50行，那么它很可能不能完整的显示在编译器的一页中，这样会导致代码不易阅读，难以理解。嵌套本来是为了方便和简化思考与代码的组织。如果有违阅读性，请别嵌套。
　　全局与区域化的SASS文件序列相当于表格内容

　　换言之，它们并没有任何一种固定样式。开发者要提醒自己保持所有部分的样式风格一致，有序。

　　首先列出厂商/全局的库，其次列出自定义库，然后是模式，最后是每个分部的用到的库。

　　这样一来‘目录‘看起来就像下面这个例子一样，一目了然：
 

　　这些文件就像是一个指南针，颜色和mixins并不产生已编译好的CSS代码，他们纯粹是独立的库。在此之后引入模式，使得重写变得更安全，不会出现专一性的冲突。
　　将SASS合理的分割成多个小文件

　　这样做没有任何不好。在情况允许的时候，尽量使用小而精的多个文件，这样便于开发者在寻找一些特定文件，而不是在几个拥有冗长代码的大文件中大海捞针。
 
...
 

　　我经常做的就是在一个全局scss文件中逐个引用这些文件，而不是引用一个_header.scss文件，然后再_header.scss文件中在逐个引用。这样做能够降低索引的时间和提高阅读效率。

　　当这些文件过多导致import序列太长时，你可能会用到 Globbing 。
　　记得将Partials命名为_partial.scss

　　这是一个常见对于不能自身编译的文件的命名。这样的文件多少会依赖于其他的文件，使得自身不能独立完成编译。我个人喜欢在文件名之前添加一个下划线，譬如_dropdown-menu.scss
　　在本地编译时添加行映射

　　看这里，这意味着开发工具能够告诉你每一条规则的来源，哪怕是一个被引入的partial文件。
　　在部署时，记得编译已精简的文件

　　运行中的网页永远都只需要使用精简的CSS。
　　无需递交.css文件

　　这可能要花些时间，但是不在文件库中放入.css文件可以是一件非常美妙的事. 文件编译在部署的时候就完成了。 所以唯一可以看见的是那些已经精简的格式美妙的sass文件。 这使得对于文件的描述变得大有用途。文件描述是用于对比由版本发布者所做的一些更改。而对于已经精简的.css文件，文件描述基本不需要了。
　　大方的使用注释

　　很少有人会后悔在代码中留下了注释。不论是有用的还是不起眼的注释，他们最终都会在编译成精简的CSS文件时被抹去，对于开发者来说不会有任何附加代价。
 
.overlay {
  /* modals are 6000, saving messages are 5500, header is 2000 */
  z-index: 5000;
}

　　提到注释，你可能也需要对它做一些标准化的调整。在SASS中，’//’非常适用于添加注释，’//’使得注释和取消注释变得非常方便。
　　将一些常用的数值和有特殊意义的数值转化成变量

　　如果你发现自己重复使用一个数值（这在前端设计里是很常见的），你最好将它转化成一个变量。这样你可以通过命名来提醒自己这个数值的含义，并且在编写代码时保持一致性，是的你在更改这个数值时不需要逐行调整。

　　若果一个数字有着明显的含义，那么将它转化成变量是必不可少的啦。
 

　　这些数字可能会被储存在单个文件中以@imported形式导入。这样的方式使得你能够对于所有的z-index或者其他变量做一个统一管理
　　将色彩转化成变量

　　除了黑与白。很多色彩都不会只是用一次，哪怕你认为你不会再用到它了。但如果你将它转化成一个变量，你可能发现在其他地方也会用到。对于色彩的变量，在sass中有color functions 可以处理他们，例如 lighten()和darkern()。这使得你对于整体的色彩控制变得简易（一次修改，一劳永逸）
　　嵌套并命名你的媒体库

　　在sass里嵌套媒体库的功能意味着1.你不必要在其他地方重写选择器而引发不必要的错误；2.你所重写的规则规则变得清晰明了，而当这些代码在你css代码的末端或其他文件中时，这将会变得非常混乱。
 

　　这里有着更详细的解释：http://css-tricks.com/naming-media-queries/
　　将Shame放在最后

　　在你的全局样式表中，在最后引入一个_shame.scss文件。
 

　　如果你需要做一些快速更改，你可以在这里修改。如果在以后你有适当的时间和精力，你可以将
_shame.scss中所做出的对整体架构的修改做一个更好的整理和构架。详情请看：http://csswizardry.com/2013/04/shame-css/
　　你是决定一切的主导

　　Sass不会做你没有告诉它的事， 所以sass文件的最终输出内容因人而已。利用sass编写css文件就像没有用sass一样，你才是代码的主导。