相信大家對樣式命名都多少感到困難，特別是想起乙個有意義的名，更難。回顧了一下之前寫的《 樣式命名規則 》（不知道大家使用後有什麼感想）結合這段時間使用上發現的一些問題，重新整理了樣式的命名規則，希望能更實用些。
要避免當狀態改變時名稱失去意義，最常見的就是用於布局的類名，如「left」、「right」，當左邊欄不再是左邊欄的時候，「left」這個名就沒有實際意義了（可以看下《 css**命名慣例語義化的方法 》中的「css類命名的語義化vs結構化方式」部分）。這與我們所推薦的「命名要有意義」就相違背了，使用序號就更加有問題了。好像沒錯，不過有好長一段時間都有個問題讓我很煩惱，如果乙個頁面中同個模組出現一次以上，而且細節還不一樣，那後面出現的名稱應該叫什麼呢？難道「one」、「two」就不是序號？其實我們要避免遇到的情況就是當狀態（表現）改變時，對應定義的類名不會失去意義。
所謂的狀態（表現）改變，有幾種情況：
html不變，樣式定義改變。如果命名使用了表示某一狀態的名稱，如「red「、「font14「等，必定會引起定義與命名不符的情況，對後繼的影響會造成比較大的影響。
樣式定義不變，html改變。html改變意味著類名可更換，也就是如果類名使用了表示某一狀態的名稱，反而更有利於修改。
樣式定義與html都改變。只需要考慮不要出現第一種情況的結果就可以了。
而實際情況並不是單純的某一種情況，更多的時候是混雜著出現的。有點遠了，回主題。
[ 模組字首 ] _ 型別 _ ( 作用 | 狀態 ) n _ [ 位置 n ]
圖例說明：
名詞說明：
模組字首
模組定義時使用的字首。
型別 定義類的內容型別。如輸入框、文字、段落等等。
作用 定義類的作用，用於對型別的補充。
狀態 定義類的狀態，用於對型別的補充。
位置 定義類所使用的位置，如首頁、導航等等，不排除使用左、右這樣的詞，但應盡量避免。
例：模組字首：
型別：作用：
狀態：位置：
中文解釋
命名中文解釋
命名文字輸入框
.input_tx
段落文字顏色
.c_tx_p
密碼輸入框
.input_pw
相簿彈出的設定層
.pop_set_photo
登入密碼輸入框
.input_pw_login
日誌設定成功提示
.hint_suc_blogset
文字顏色
.c_tx
公共提示
.hint_gb
問幾個簡單的問題，可以幫助我們完成命名：
「什麼型別的定義？」——是個輸入框，input。
「型別補充說明」——如果乙個詞說明不清楚，那麼補充說明型別，文字輸入框，input_tx。
「在哪使用？」——定義要使用的位置在哪？首頁的搜尋文字輸入框，input_search_index。
可能無法覆蓋到所有的情況，但相信能解決70%~80%的命名問題。如果結合「模組化」相關的方法去定義，其實所需要定義的名稱並不需要很多。如：「hint_tx」表示提示模組的文字定義，「hit_tx_hint」表示提示裡文字強調的定義，至於是改變顏色還是加粗，這個就看不同提示模組的需要了。
匈牙利命名規則
匈牙利命名規則建議變數名稱以乙個或多個字母開頭，這些小寫字母用以標識其變數型別，型別標識字母的下乙個字母一般採用大寫。型別定義使用相同的型別識別符號作為字首，唯一不同的是，型別定義名稱一般全部使用大寫。表1 匈牙利命名規則約定 字首 資料型別 例子 b boolean bispresent,bval...
元件命名規則
元件命名規則 c和p的命名規則 tinyos 所有的終端程式元件都以字母c或p為結尾。以c結尾所命名的元件表示它是乙個可用的抽象，而以p結尾的元件則表示它是私有的。以p結尾的元件不能被直接的連線，但可以對它做一些封裝以使它變成可用 變成名字以c結束的 硬體平台抽象命名規則 tinyos 2.0中的硬...
NAND FLASH命名規則
基於網路的乙個修訂版 搜了下東芝的好像比較少有介紹，就找到乙個表，貼上 型號 結構 頁結構 塊結構 工作電壓 v 溫度 讀速度 ns 封裝 生產狀態 注釋 2gb th58nvg1s3aft05 256m x 8 2112b 128kb 2.7 3.6 c,i 50 48tsop i 量產 1gb ...