SASS樣式指南

　　隨著越來越多的開發者使用SASS，我們有必要關注一下SASS的程式碼的個數問題。 我們可以從CSS（層疊樣式表）的語法出發，來解釋SASS語法的一些特別之處，畢竟，CSS樣式指南是很常見的。

　　這篇文章主要介紹了我個人比較感興趣的一些特性，也許能夠讓你從中受用，形成一套屬於自己的SASS使用指南。

　　繼續保持自己常用的CSS格式規則和樣式指南

　　這篇文章著重討論了關於SASS的一些內容，但是在此基礎上，開發者應該保持自己已有並且良好的格式規則。如果你還沒有發展出一套屬於自己的格式規則，那麼這裡有一些樣式指南的綜述，應該可以幫你形成屬於自己的CSS編寫習慣。這裡僅列出一些其中所包含的部分內容：

• 1. 保持行縮排一致
• 2. 保持冒號/大括號前後空格數的一致
• 3. 保持一行一個選擇器，一行一個規則
• 4. 相關的屬性儘量寫在一起
• 5. 對於類名命名規則由一個規劃
• 6. 避免使用CSS id選擇器
• 7. 等等

　　接下來我們就瞭解一下如何寫出美觀的SASS程式碼吧，以編寫一個.weather類的屬性為例：

　　首先列出@extend(s)

.weather {
  @extends %module; 
  ...
}

　　這樣做能夠使開發者保持一個清晰的思路，能夠立刻知道這個類與其屬性和其他類及其屬性的關係，保持屬性的一致和屬性重用的清晰思路。

　　普通樣式

.weather {
  @extends %module; 
  background: LightCyan;
  ..
}

　　@include(s)

.weather {
  @extends %module; 
  background: LightCyan;
  @include transition(all 0.3s ease-out);
  ...
}

　　這樣做能夠使開發者一眼看出@extend(s)和@include(s)的部署，便於自己以及其他開發者對程式碼的解讀。你可能還會對是否區分自定義的@includes和公共來源的@includes在有些情況下做出決定（尤其是考慮到程式碼的可重用性和時效性）

　　選擇器巢狀

.weather {
  @extends %module; 
  background: LightCyan;
  @include transition(all 0.3s ease);
  > h3 {
    border-bottom: 1px solid white;
    @include transform(rotate(90deg));
  }
}

　　在巢狀部分內，繼續使用上述的樣式規則。巢狀的部分永遠都應該放在最後。

　　所有廠商字首使用@mixins

　　廠商字首（CSS字首）具有非常強的時效性。 由於現代瀏覽器的更新，這些字首的使用將越來越少。你可以通過更新mixins裡的內容（或者在你mixin裡用到的一些庫將自動更新）去適應這些變化。 哪怕mixin只有短短一行，也沒有關係。
但當某些廠商字首的私有化非常嚴重時，這些字首將非常難以標準化並且應用其他字首或者無字首的版本會得不償失，我會選擇放棄@mixin這些廠商字首。比如像-webkit-line-clamp， -mscontent-zoom-chaining或者類似情形。

　　巢狀的層次不要超過3層

.weather {
  .cities {
    li {
      // no more!
    }
  }
}

　　如果你的巢狀多餘三次，你很有可能寫出一個坑爹的（差勁的？）選擇器。坑爹的原因不外乎這個選擇器過於依賴HTML的架構（不穩定）， 過於詳細（功能過於強大，沒有彈性），或者是可重用性太差（不太可用）。同時，過多的巢狀層次容易導致程式碼處於晦澀難懂的境地。

　　如果有的時候與類相關的程式碼真的太多了，使得你不得已使用標籤選擇器。你可能需對於某個類要寫的非常具體，以避免不必要的層疊。 甚至有可能的話，利用extend來使用CSS裡一些可重用性的特性。

.weather
  > h3 {
    @extend %line-under;
  }
}

　　巢狀的程式碼不要超過50行

　　若果SASS裡的巢狀多於50行，那麼它很可能不能完整的顯示在編譯器的一頁中，這樣會導致程式碼不易閱讀，難以理解。巢狀本來是為了方便和簡化思考與程式碼的組織。如果有違閱讀性，請別巢狀。

　　全域性與區域化的SASS檔案序列相當於表格內容

　　換言之，它們並沒有任何一種固定樣式。開發者要提醒自己保持所有部分的樣式風格一致，有序。

　　首先列出廠商/全域性的庫，其次列出自定義庫，然後是模式，最後是每個分部的用到的庫。

　　這樣一來‘目錄‘看起來就像下面這個例子一樣，一目瞭然：

/* Vendor Dependencies */
@import "compass";

/* Authored Dependencies */
@import "global/colors";
@import "global/mixins";

/* Patterns */
@import "global/tabs";
@import "global/modals";

/* Sections */
@import "global/header";
@import "global/footer";

　　這些檔案就像是一個指南針，顏色和mixins並不產生已編譯好的CSS程式碼，他們純粹是獨立的庫。在此之後引入模式，使得重寫變得更安全，不會出現專一性的衝突。

　　將SASS合理的分割成多個小檔案

　　這樣做沒有任何不好。在情況允許的時候，儘量使用小而精的多個檔案，這樣便於開發者在尋找一些特定檔案，而不是在幾個擁有冗長程式碼的大檔案中大海撈針。

...

@import "global/header/header/";
@import "global/header/logo/";
@import "global/header/dropdowns/";
@import "global/header/nav/";
@import "global/header/really-specific-thingy/";

　　我經常做的就是在一個全域性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中，’//’非常適用於新增註釋，’//’使得註釋和取消註釋變得非常方便。

　　將一些常用的數值和有特殊意義的數值轉化成變數

　　如果你發現自己重複使用一個數值（這在前端設計裡是很常見的），你最好將它轉化成一個變數。這樣你可以通過命名來提醒自己這個數值的含義，並且在編寫程式碼時保持一致性，是的你在更改這個數值時不需要逐行調整。

　　若果一個數字有著明顯的含義，那麼將它轉化成變數是必不可少的啦。

$zHeader: 2000;
$zOverlay: 5000;
$zMessage: 5050;

.header {
  z-index: $zHeader;
}
.overlay {
  z-index: $zOverlay;
}
.message {
  z-index: $zMessage;
}

　　這些數字可能會被儲存在單個檔案中以@imported形式匯入。這樣的方式使得你能夠對於所有的z-index或者其他變數做一個統一管理

　　將色彩轉化成變數

　　除了黑與白。很多色彩都不會只是用一次，哪怕你認為你不會再用到它了。但如果你將它轉化成一個變數，你可能發現在其他地方也會用到。對於色彩的變數，在sass中有color functions 可以處理他們，例如 lighten()和darkern()。這使得你對於整體的色彩控制變得簡易（一次修改，一勞永逸）

　　巢狀並命名你的媒體庫

　　在sass裡巢狀媒體庫的功能意味著1.你不必要在其他地方重寫選擇器而引發不必要的錯誤；2.你所重寫的規則規則變得清晰明瞭，而當這些程式碼在你css程式碼的末端或其他檔案中時，這將會變得非常混亂。

.sidebar {
  float: right;
  width: 33.33%;
  @include bp(mama-bear) {
    width: 25%;
  }
}

　　這裡有著更詳細的解釋：http://css-tricks.com/naming-media-queries/

　　將Shame放在最後

　　在你的全域性樣式表中，在最後引入一個_shame.scss檔案。

@import "compass"

...

@import "shame"

　　如果你需要做一些快速更改，你可以在這裡修改。如果在以後你有適當的時間和精力，你可以將
_shame.scss中所做出的對整體架構的修改做一個更好的整理和構架。詳情請看：http://csswizardry.com/2013/04/shame-css/

　　你是決定一切的主導

　　Sass不會做你沒有告訴它的事， 所以sass檔案的最終輸出內容因人而已。利用sass編寫css檔案就像沒有用sass一樣，你才是程式碼的主導。

　　英文原文：css tricks，編譯：感謝@Little2Mao 翻譯。