编者注：本文是我们的代码优化系列的一部分，我们在其中探讨如何优化编码以提高效率，以期成为更好的编码人员。
就像jQuery如何革新了香草JavaScript一样， Sass也革新了香草CSS 。 大多数学习Sass的开发人员都同意，他们永远都不想回头。 许多人还同意，新开发人员面临的最大问题是他们使用Sass的方式 ，而不是Sass本身。
我遍历了网络，并汇编了本文的最佳实践，以编写可扩展和可重用的Sass代码 。 建议来自我自己的意见，也来自Sass Guidelines等受信任的网站。
您当然不需要在工作流程中实现所有这些功能。 但是，至少应该招待这些想法并考虑潜在的好处是值得的。
了解更多： 通过本指南开始使用SASS
文件组织
从Sass开发开始的最佳位置是文件组织。 如果您已经开始使用模块化代码，那么您应该了解import和partials的价值（稍后会详细介绍）。
但是现在来看一下DoCSSa中的这个文件结构示例。 我已经重新创建了这个文件结构，您可以在下面看到它：
这只是一个建议，它是组织文件的多种方式之一。 您可以找到其他使用不同文件夹结构的方法 ，例如对于站点范围的SCSS使用“全局”，对于特定于页面的SCSS使用“页面”。
让我们遍历这种建议的组织样式，以检查每个文件夹的用途：
- / globals –包含在站点范围内应用的Sass文件，例如版式，颜色和网格
- / components –包含具有按钮，表格或输入字段等组件样式的Sass文件
- / sections –包含专用于特定页面或页面区域的Sass文件（可能更好地组合到/ components /文件夹中）
- / utils –包含第三方实用程序（如Normalize），可以使用Bower之类的工具动态更新。
- main.scss –导入所有其他文件的根文件夹中的主Sass文件。
这只是一个基本的起点，您可以根据自己的想法进行扩展。
但是，无论您如何选择组织SCSS，至关重要的是， 对于某些需要更新的库（如Normalize ）， 要有一些单独的文件（或文件夹）进行组织 ，以及项目的Sass局部中的组件。
Sass部分对于现代最佳实践至关重要。 Zurb的设计团队和许多其他专业的前端开发人员强烈推荐这些。
这是Sass网站上引述部分内容的引文：
“您可以创建部分Sass文件，其中包含一些CSS片段，您可以将其包含在其他Sass文件中。 这是模块化CSS并帮助使事情易于维护的好方法 。 部分文件只是一个以下划线开头的Sass文件。 您可能将其命名为_partial.scss 。 下划线让Sass知道该文件只是部分文件，不应将其生成为CSS文件。 Sass局部函数与@import指令一起使用。”
还可以查看有关Sass文件结构的其他文章：
导入策略
关于Sass导入和部分的值还不能说足够。 代码组织是获得可以正常使用的导入结构和工作流程的关键。
最好的起点是从包含导入，变量和混合的全局表 。 许多开发人员更喜欢将变量和mixin分开，但这归结为语义。
请记住，mixins是导入或复制Sass代码的一种方法 。 它们非常强大，但不应与“静态”代码一起使用。 请记住， mixin，extends和占位符之间是有区别的，所有这些都在Sass开发中使用。
阅读更多： 11个面向设计师的Sass mixin库
最好将Mixins与传递给mixin的动态值一起使用以进行代码更改。 例如，检查此Sass mixin ，它在两种颜色之间创建背景渐变。
@mixin linearGradient($top, $bottom){
background: $top; /* Old browsers */
background: -moz-linear-gradient(top, $top 0%, $bottom 100%); /* FF3.6+ */
background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,$top), color-stop(100%,$bottom)); /* Chrome,Safari4+ */
background: -webkit-linear-gradient(top, $top 0%,$bottom 100%); /* Chrome10+,Safari5.1+ */
background: -o-linear-gradient(top, $top 0%,$bottom 100%); /* Opera 11.10+ */
background: -ms-linear-gradient(top, $top 0%,$bottom 100%); /* IE10+ */
background: linear-gradient(to bottom, $top 0%,$bottom 100%); /* W3C */
filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#ffffff', endColorstr='#000000',GradientType=0 ); /* IE6-9 */
}
mixin具有两个值：顶部颜色和底部颜色。 您可以为包含3或4+种不同颜色的不同类型的渐变编写不同的mixin。 这使您可以在更改自定义选项的参数时导入和克隆混合代码。
代码负责人的示例如下所示：
.button{
@include linearGradient(#cccccc, #666666);
}
与mixin相关的是Sass的占位符 ，它主要与extend指令一起使用 。 公认它比mixins更复杂，但这是将选择器组合在一起而不重写多余代码的一种方式。
尽管Sass只有一种@import方法，但我包含了mixins和占位符，以演示可以写在一个文件中但可以包含在任何地方的代码的灵活性。
构建导入结构时，请记住遵循DRY编码的概念（请勿重复自己）。
命名约定
命名约定的一般规则适用于变量，函数和混合。 在Sass中命名任何内容时，建议使用所有带有短划线的小写字母进行分隔 。
Sass代码语法实际上是基于CSS准则规则集的。 请记住以下一些建议的最佳做法：
- 两（2）个空格缩进，没有制表符
- 理想情况下，宽度不超过80个字符
- 有意义地使用空白
- 使用注释来解释CSS操作
这些不是有效Sass代码的必需项。 但是这些建议来自专业开发人员， 他们发现这些规则集提供了最统一的编码体验 。
但是，关于命名约定，您可能会得到两种不同的结构：一种用于Sass名称，另一种用于CSS类名称。 一些开发人员更喜欢BEM，而不是Sass建议。 没有一个或多或少是正确的。 只是不同的操作程序而不同。
在此处阅读有关BEM的更多信息： 了解CSS编写方法
问题在于BEM不能很好地传递到Sass变量或mixins，因为它们没有块/元素/修饰符（BEM）结构。 我个人更喜欢使用Sass命名约定，但是您可以尝试从camelCase到您自己的内部语法的任何内容。
在组织变量和mixin时，建议按类别将其拆分，然后按字母顺序列出 。 这使编辑变得更加容易，因为您确切地知道在哪里可以找到东西。
例如，要更改链接颜色，您可以打开变量文件（也许是_variables.scss ），然后找到用于颜色变量的部分。 然后按名称查找链接（标题链接，文本链接等）并更新颜色。 简单！
要了解如何为Sass文件构建目录，请查看Foundation的设置文件 。
// Foundation for Sites Settings // ----------------------------- // // Table of Contents: // // 1. Global // 2. Breakpoints // 3. The Grid // 4. Base Typography // 5. Typography Helpers ... // 1. Global // --------- $global-font-size: 100%; $global-width: rem-calc(1200); $global-lineheight: 1.5; // etc
另一种命名方式与响应断点有关 。 在命名Sass断点时 ，请尝试避免使用设备特定的名称。 最好写出诸如small，med，lg和xlg之类的名称，因为它们彼此之间是相对的 。
这对于断点之间的内部关系更好，但对于开发人员可能不知道哪些设备相互关联的团队也非常有用。
至于实际放下名称，建议您尽量不要使用多余的变量 。 您应该采用站点范围的命名约定，这些约定在编码时很容易记住 。
给出所有颜色，边距，字体堆栈和行高的特定命名约定。 不仅可以快速调用这些名称，而且在编写需要与现有语法匹配的新变量名称时使您的工作更加轻松 。
但是特异性和卷积之间有一条细线 。 练习将帮助您找到这一行，并且编写更易记的名称可以使将代码复制到其他项目中更加容易。
嵌套和循环
这两种Sass技术在操作上有很大不同，但是如果不慎重使用 ，它们都有被滥用的能力 。
嵌套是通过缩进添加选择器嵌套在一起的过程， 以更少的代码创建更多的特性 。 Sass有一个嵌套指南，该指南说明了实际中的代码嵌套示例。 但是很容易被嵌套困扰。 如果您过分热心，则可以得到如下代码：
body div.content div.container { ... }
body div.content div.container div.articles { ... }
body div.content div.container div.articles > div.post { ... }
这种类型的代码过于具体，几乎无法覆盖，无法实现级联样式表的目的。
浏览此SitePoint指南，您会发现嵌套的三个黄金法则：
- 深度不能超过3个级别。
- 确保CSS输出干净且可重复使用。
- 在有意义的情况下使用嵌套，而不是将其作为默认选项。
开发人员Josh Broton建议在必要时嵌套，将其余缩进作为通用语法规则。
缩进选择器不会导致任何级联CSS效果。 但是，您将可以更轻松地浏览Sass文件，从而准确确定哪些类彼此相关。
如果使用不当，循环也可能被过度使用 。 三个Sass循环是@for ， @while和@each 。 我不会详细介绍它们如何工作，但是如果您有兴趣的话， 请查看这篇文章 。
相反，我想介绍使用循环的目的以及它们在Sass中的功能。 这些可用于节省编写自动化代码的时间。 例如，这是Clubmate帖子中的代码片段，其中显示了一些Sass代码以及其输出：
/* Sass code */
@for $i from 1 through 8 {
$width: percentage(1 / $i)
.col-#{$i} {
width: $width;
}
}
/* output */
.col-1 {width: 100%;}
.col-2 {width: 50%;}
.col-3 {width: 33.333%;}
.col-4 {width: 25%;}
.col-5 {width: 20%;}
.col-6 {width: 16.666%;}
.col-7 {width: 14.285%;}
.col-8 {width: 12.5%;}
这些列类可以与网格系统结合使用。 您甚至可以通过编辑循环代码添加或删除更多列。
循环不应该用于复制选择器或选择器的属性 ； 这就是mixin的用途。
同样，在循环时，有一个称为Sass映射的东西存储了key：value对数据。 高级用户应尽可能利用这些优势。
但是常规的Sass循环在不重复的情况下提供代码输出既简单又有效 。 使用循环的最佳原因是CSS属性会改变数据输出 。
这是检查循环是否有用的好方法：问问自己是否还有其他方法可以用更少的代码行输出所需CSS 。 如果没有，那么循环语法可能是一个好主意。
如果您感到困惑或需要有关嵌套或Sass循环的反馈，则应该在/ r / sass /或/ r / css /中发布问题 ，活跃的Reddit社区应具有丰富的Sass开发人员知识。
模块化
编写模块化Sass的实践对于大多数项目都是绝对必要的（我想，每个项目）。 模块化是将项目分解为较小模块的过程 。 这可以在Sass中使用partials完成。
模块化Sass背后的想法是编写具有特定目的的单个SCSS文件，这些文件针对全局内容（印刷术，网格）或页面元素（标签，表单）。
Sass模块的定义非常清楚，并提出了非常具体的建议： 导入模块永远不要输出code 。
所有模块强制输出的想法将是优化的噩梦。 相反，您应该单独创建模块，并仅调用所需的模块。 可以通过mixin或函数定义模块，但是也可以创建包含选择器的模块。
但是， Sass Way的文章建议将所有选择器编写为mixin，并仅在需要时调用它们。 最终，您是否选择采用此方法。 我认为这取决于项目的规模以及您对处理mixin的满意程度。
引用约翰·朗（John Long）在他的 《无礼的方式》中的文章：
“对我来说，模块已成为我的Sass项目的基本单元或构建块。”
如果您真的在寻找Sass例程，我建议您完全模块化。 尝试将几乎所有内容构建为模块化部分，并将其包含在主CSS文件中。 起初，这个工作流程看似令人生畏，但在更大范围内是有意义的，尤其是在大型项目中。
此外，当模块位于单独的文件中时，将模块从一个项目复制到另一个项目要容易得多。 灵活性和可重用代码是模块化开发的基石。
要了解有关Sass模块和模块化技术的更多信息，请查看以下文章：
找到理想的工作流程
每个团队和单个开发人员都有自己的最佳实践。 您应该采用最适合自己的实践，或者选择采用最适合您的团队的实践。
还可以考虑使用Gulp或Grunt进行项目自动化并减少代码。 这将节省大量的人工，而自动化工具无疑已经成为现代前端开发最佳实践的一部分。
浏览GitHub上Foundation的SCSS等开源库，以了解有关其他库采用的最佳实践的更多信息。
关于最佳做法的事情是，它们大多数时候确实可以改善您的工作，但是有很多选择。 尝试一下，看看它们的感觉。 您将一直在学习，因此您的最佳做法可能会在5年内Swift变化。
对于整个Sass流程，我最后的建议是在做出决策时要牢记清晰 。 编写使您的工作更轻松的代码。 如果有更简单的方法，请不要使项目过于复杂 。
Sass旨在增强CSS开发体验，因此请保持清晰明了和最佳实践，以获取最佳体验。
阅读更多： 一个简单易懂的指南，帮助理解Sass
包起来
可以通过调整代码样式并遵循最佳实践来纠正Sass工作流中的拥塞。 我在这篇文章中概述了Sass博客和专业开发人员的一些建议。
了解更多信息的最佳方法是将这些实践应用到您的工作流程中，并查看有效的方法 。 随着时间的流逝，您会发现某些活动比其他活动更有益，在这种情况下，您应该保留所有有效的方法，而放弃无效的方法 。
查看这些链接，以找到有关Sass开发的更多技巧和最佳实践：
翻译自: https://www.hongkiat.com/blog/sass-tips-tools-for-developers/