**： （譯者：kayson）編寫css容易。
編寫可維護的css難。
這句話你之前可能聽過1
00次了。
原因是css中的一切都預設為全域性的。如果你是乙個c程式設計師你就知道全域性變數不好。如果你是任何一種程式設計師，你都知道隔離和可組合的模組是構建可維護系統的關鍵。
為了試圖幫助人們構建可維護的css，已經有很多css指南了：smacss, oocss, bem, itcss, acss, ccss,atomic design, maintanable css, rscss, 並且可能還有 更多.
那麼，css的問題是什麼？
用乙個如上的css定義，樣式立馬變成全域性的，它會影響所有應用樣式的頁面。沒有封裝。沒有隔離的模組。span
.header
-right
在乙個標準的程式語言裡，你只會為了要實現的特定功能引入一些模組，例如：
這樣，你準確地知道什麼會影響你的**，並且只有你顯式引入的內容才會影響到你當前正在實現的功能。# python modules
importrequests
fromflask
import
url_for
// node modules
varexpress
=require
(『express
』)
而在css中是反過來的。我每寫一行css**，可能會影響到專案裡的所有部分，並且會無意間改變其他頁面的外觀。我的樣式不僅僅是洩露；它們蜂擁而出，遍布應用程式的每個角落。
然而，世界變了，web也變了。我們不再製作網頁——我們構建web應用程式。html和css為之建立的出版物隱喻，不再適用於當今建立在web之上的大部分事物。
這確實需要一種 指定樣式的新方式，也許還要一種構建web的新方式。但是就目前來說，我們還無法擺脫css和html，這意味著我們不得不用一種產出可管理和可維護的應用程式的方式小心地使用這些工具。
法則一：（給類名）加上字首
在peergrade.io我們在所有類名中用了字首 .pg 。在css**庫里不使用字首是自找麻煩。原因就是不加字首的類名最終將會跟引入的樣式衝突。假設你需要乙個datepicker ——你肯定不願意從頭開發乙個（至少我不願意），因此你引入了乙個。現在你的樣式裡到處都是.prev, .next, 和 .separator這樣的類名，可能會跟你自己的類名衝突——如果你不加字首的話。
很長一段時間 font awesome沒有在他們的類名上加字首，這意味著你經常跟他們的.icon-* 類名發生衝突（他們現在用了字首 .fa）。我們也難過地發現 bootstrap 也沒有選擇加字首——但我們依然 ❤ 你, mark otto。
法則二：避免使用css選擇器巢狀
在peergrade.io我們使用 sass。使用 sass 你很快進入一種sass結構跟html結構相匹配的模式，例如：
這麼做之後你會發現，儘管感覺不錯，但它非常脆弱。在你寫它的時候你可能認為在.profile-description裡只會有乙個列表，但一兩個月後你發現不得不需要另外乙個列表，頁面結構很快超出你的設想。#user-profile-page
.profile
-description
h3
ul
li
a
並且，像這樣的樣式定義會應用到父元素內部的任何元素上——而不僅僅是你寫在sass裡的那個層級。
對css選擇器巢狀你所做的是用 微妙 和 脆弱的方式繫結css和html結構。
法則三：採用bem命名來開發元件
在構建可隔離元件時，盡可能採用bem命名方案給類命名。我們沒有遵循完整的bem指南——只是命名方案，這就是說類名應該是這種形式：
.
block__element
--modifier
這裡你看到的是我們用sass巢狀為我們建立bem類名。有點反直覺的是，這會產生完全扁平的css結構——沒有巢狀——只有頂層的類名定義。.pg-deadline
&__date
// becomes `.pg-deadline__date`
color:$color
-gray
&__header
// becomes `.pg-deadline__header`
font-weight
:700
&--highlight
// becomes `.pg-deadline__header--highlight`
color:$color
-green
作為法則二的乙個例外，我們允許 .block–modifier 形式的類名。
在這個特殊的例子中，我們允許 1層css選擇器巢狀。這就允許我們只要指定區塊的修飾符——也就是正在編輯的內容—— 不用在區塊內的所有子元素上重複修飾符（bem中的e）。.pg-deadline
--editable
.pg-deadline__header
background-color
:$color
-blue
.pg-deadline__date
color:$color
-black
為了更好地理解類似bem的命名方式，前往檢視harry roberts的css指南的類bem命名部分。（需要提到的是，我們發現harry實際上建立了一套跟我們類似的命名方案。）
似乎還沒有人真正找到處理css的最佳方式，看著hack news上精選的這篇文章，我對css的現狀多少有點失望，本來我們可以做得更好。
結論就是：我們相信已經找到了css的可持續基礎——當然還有改進的空間。這個計畫就是經常對照檢查我們的指南，看看事情是不是朝我們預期的方向發展，並且在必要的時候修訂。
end
大型專案中函式過載的應用
今天主要是寫繼承類如何過載父類函式，並呼叫繼承函式。下面從例項出發介紹。include using namespace std class a void getdata int a,int b int setdata int a,int b int getresult private int c,d...
makefile之大型專案
管理linux環境下的c c 大型專案，如果有乙個智慧型的build system會起到事半功倍的效果，本文描述linux環境下大型工程專案子目錄makefile的一種通用寫法，使用該方法，當該子目錄內的檔案有增刪時無需對makefile進行改動，可以說相當的智慧型。下面先貼 為減小篇幅，一些非關鍵...
大型專案的特點
二 高併發 三 集群 四 海量資料 將專案按照特定的規則拆分成多個子專案，分開來發布一般在大型專案中使用使用傳統專案 單個專案 開發時，如果其中乙個功能模組出現問題，可能會影響到整個專案的使用。為了解決這種問題，使用了分布式，將專案的功能模組在架構層級松耦合分布式主要有兩種拆分方式 垂直拆分和水平拆...