命名约定

优质
小牛编辑
124浏览
2023-12-01

在本节,我们不会讨论适用于大规模和可维护的最佳 CSS 命名方案,因为这不仅仅超过了个人的能力范围,也不是一个Sass样式指南可以解决的问题。我个人推荐遵从 CSS Guidelines 的建议。

良好的命名对保持整体代码的一致性和可读性非常重要,在 Sass 中可以命名的地方如下:

  • 变量;
  • 函数;
  • 混合宏。

由于 Sass 占位符遵循和类名相同的命名模式,因此被视为常规的 CSS 选择器,也就在这个列表中故意忽略掉了。

就变量、函数和混合宏的命名而言,我们坚持一些很 CSS-y 的风格:小写连字符分隔,有意义的命名。

$vertical-rhythm-baseline: 1.5rem;

@mixin size($width, $height: $width) {
  // …
}

@function opposite-direction($direction) {
  // …
}
$vertical-rhythm-baseline: 1.5rem

=size($width, $height: $width)
  // …

@function opposite-direction($direction)
  // …

常量

如果你恰巧是一个框架开发者或某个库的维护者,你会发现自己正在使用的变量并不需要在所有情况下都进行更新:此时是多么类似一个常量。不幸的是(或者幸运的是?),Sass 不提供任何方式定义这样的实体,所以我们要坚持严格的命名约定来阐述我们的想法。

对于众多编程语言,我建议使用全大写方式书写常量。这不仅是一个由来已久的编程习惯,而且可以很好的与小写连字符变量加以区别。

// Yep
$CSS_POSITIONS: (top, right, bottom, left, center);

// Nope
$css-positions: (top, right, bottom, left, center);
// Yep
$CSS_POSITIONS: (top, right, bottom, left, center)

// Nope
$css-positions: (top, right, bottom, left, center)

如果你在 Sass 中使用常量,请参考这篇文章:如何在 Sass 中使用常量.

命名空间

如果你打算分发你的 Sass 代码,比如一个库、框架、栅格系统或者其他的什么,为了防止与其他人的代码发生冲突,你就可能会考虑使用命名空间包裹你所有的变量、函数、混合宏和占位符。

举例来说,如果你参加了一个名为 Sassy Unicorn 的项目 —— 这意味着你可以向其贡献代码,你可能会考虑使用 su- 作为一个命名空间。这确实非常独特,既不会引发命名冲突,又足够短小而没有书写困难。

$su-configuration: ( … );

@function su-rainbow($unicorn) {
  // …
}
$su-configuration: ( … )

@function su-rainbow($unicorn)
  // …

关于 CSS 的全局命名,Kaelig 写过 一篇非常具有思考价值的文章

需要注意的是,自动命名空间功能绝对是即将到来的Sass4.0中重构的@import的一个设计目标。随着即将取得结果,将会越来越少的需要手动命名,最终,手动命名库名实际上会越来越难用。