本文首發於政採雲前端團隊博客：編寫高質量可維護的代碼：優雅命名css
https://www.zoo.team/article/good-name
前言
俗話說得好，萬事開頭難。而對於前端 coder 來講，每次新項目、新需求來的時候，我想你們最苦惱的每每就是如何去命名，不管是項目名稱、頁面的文件名稱亦或是代碼中的方法名稱，對於我來講，但凡名字想好了之後，我以爲需求就已經寫完一半了。html
如何才能更好，更優雅的去解決這些命名問題呢？在這以前，先隨我看一些不合適的命名示例吧。前端
不合適的命名
咱們先來看一些例子：git
-
無心義的，抽象的，任何地方可使用，誰都不知道你這裏用的命名來源是誰
// bad
const data;
const info;
const tool;
-
簡稱，單詞的簡稱或者縮寫很容易讓人沒法肯定具體指代什麼
// bad
const comp;
const crt_date;
// good
const components;
const company;
const current_date;
-
數字或者字母結尾的命名，讓其餘人沒法獲取這些之間的區別
// bad
const button1;
const button2;
const info1;
// good
const importButton;
const userInfo;
-
全局的地方不要用前置或後置下劃線，前置下劃線一般表明了私有變量
// bad
const _firstName_ = 'Zcy';
const firstName_ = 'Zcy';
const _firstName = 'Zcy';
// good
const firstName = 'Zcy'
命名規則
如何讓命名更簡單呢，只要遵循一些規則規範，總能將複雜的事情拆分開來，變成一件簡單的事情。github
直白、有意義
想要讓你的命名簡單易懂，最簡單的方式就是直白而且有意義，直接了當的在命名中體現出你這個命名的功能，或者描述，舉個例子：web
// bad
function getInfo(){};
function formatList(){};
const data = [];
// good
function getUserInfo(){};
function formatNewsList(){};
const articleData = [];
若是在頁面中定義了上面這樣的變量，哪一種寫法可讓你在沒有註釋的狀況下，就能快速瞭解原做者的書寫意圖呢？（固然，代碼中仍是須要一些必要註釋的）。npm
因此在命名的時候，須要的就是直白、完備、有意義，讓別人經過命名就能瞭解到這個名稱（不管是變量、方法或者是樣式名）背後的的含義，這樣的命名就是高效的、易懂的。json
聽從慣例、標準
習慣使用業界習慣的命名標識，或者是約定俗成的書寫習慣。sass
-
用
id當作數據標識命名，而不是identifier微信 -
例如布爾值命名類型，一般只有兩個值類型：真，假，根據不一樣的使用場景，也能夠有一些經常使用的命名方式
// 可見、狀態等，可用 is+動詞/形容詞的方式
const isVisible;
const isLoading;
// 配置，選項等類型，能夠用 withXxx、hasXxx 來標識是否有某個屬性等,enableXxx 來表示是否開啓配置
const withTab;
const hasPlan;
const enableFilter;
-
例如方法命名，也可使用動詞 + 名次類的組合命名方式，操做類方法 fetchXxx，getXxx，當須要根據某些屬性獲取數據時可用 ，getXxxByYxx 這類的命名，刪除類方法 deleteXxx，格式化數據 formatXxx
// 數據獲取方法
function getUserInfo(){};
function fetchSearchList(){};
// 須要根據一些屬性去獲取數據
function getGoodsById(){};
function queryUserByName(){};
// 刪除數據
function deleteUser(){};
function removeGoodsItem(){};
// 格式化數據
function formatDate(){}；
function sortByDesc(){}
規範約束
團隊若是用統一的命名規範，那就必定要遵照，例如文件名的命名是大寫字母開頭的駝峯寫法，那你的命名就不能再修改成其餘方式，在規範建立之初或者修訂時能夠提出修改意見並進行討論，但若是已經確立的，就不要再。去自由的破壞規範。
固然也可使用一些輔助手段幫助約束代碼中的命名校驗，例如在 Eslint 配置中加入 id-match 或者 camelcase，前者能夠直接經過正則配置本身須要的命名規範，後者則是直接採用了駝峯命名的規範約束。
這裏也舉例介紹一下在 VsCode 中 Eslint 的使用
-
首選電腦全局安裝 eslint
npm install eslint -g
-
VsCode中安裝ESlint插件而且啓用
-
在本身項目中，執行 eslint --init命令來建立項目的.eslintrc.js文件，以後能夠在.eslintrc.js文件中的rules規則添加上規範的約束條件來使用這個規則
module.exports = {
"rules": {
"id-match": ["error", "^[a-z]+([A-Z][a-z]+)*$"],
"camelcase": ["error", {"properties": "always"}]
}
}
-
項目中若是碰到不符合規範的就會直接報錯提示
命名規範推薦
上面簡單介紹了一些命名的規則，那麼具體到實際操做中，咱們又有哪些較好的命名規範能夠選擇呢？下面根據不一樣的使用場景，也簡單給你們介紹一些常常推薦使用的命名規範。
項目名稱、文件名稱
項目或者單文件的命名方面，常見規則：
-
kebab-case：橫短線命名，也叫串式命名法，小寫字母的詞組，中間加-拼接的方式，這種方式命名便於同類內容快速查找
// good
news-index;
news-list;
news-detail;
-
camelcase：小駝峯命名，第一個單字以小寫字母開始，第二個單字的首字母大寫
// good
newsIndex;
newsList;
newsDetail;
JavaScript
-
變量：經常使用小駝峯命名
// good
const userInfo;
const userAddressList;
const currentDate;
-
所有使用大寫字母，單詞之間採用 _分割
// good
const ITEM_LIST;
const PAGE_ITEM_LIST;
const DEFAULT_CONFIG;
-
方法：小駝峯命名，而且推薦命名時添加一些動詞類，能夠幫助快速理解方法含義，例如以 handle 開頭，中間 xxx 表示操做內容，show 表示具體操做， handlexxxxChange，handlexxxxShow，而好比數據獲取能夠用 get，fetch 這類
// 小駝峯命名
function getUserInfo(){};
function addSuplierInfo(){};
// 添加一些操做類的輔助命名
function handleUserInfoChange(){};
function handleTitleClick(){};
function fetchPageData(){};
-
類名：大駝峯命名
export class CommonLogo;
export class CartCenter;
css
BEM 規範
BEM 是一種命名 CSS 樣式的命名方法和規範，全稱 Block（塊）、 Element（元素）、Modifier（修飾符） ，想必不少人都比較熟悉了。
Block：通常能夠看作是獨立具備實際意義的模塊部分，例如 header,container,menu 等
Element：組成 Block 的一部分，沒有具體的實際意義，通常也不獨立使用，例如 menu item，list item，header title 等
Modifier：通常是塊或者元素的修飾狀態或者行爲，例如 disabled，color，checked 等
而 BEM 的寫法通常是 .block-name__element-name--modifier-name，其中 Block 與 Element 之間鏈接是經過 __ 雙下劃線，Block，Element 與 Modifier 之間是經過 -- 雙中劃線進行鏈接，當使用less或者 sass 語法編寫 css 時，經過嵌套語法也可以很簡潔的書寫這部分樣式。
<div class="head">
<div class="head__title">
標題
<div class="head__title--disabled">
置灰內容
</div>
</div>
</div>
.head {
background-color: #fff;
&__title {
font-size: 14px;
color: #666;
&--disabled: {
color: #f00;
}
}
}
BEM 命名規範可讓樣式的命名更加模塊化，組件之間結構獨立，減小了命名之間的衝突，有着不錯的易讀性、維護性等等，但可能會讓項目中的樣式命特別的長。
下面也有一些使用 BEM 命名規範的網站，有興趣的能夠去看看：
-
https://csswizardry.com/
-
https://mediatemple.net/
-
https://www.udemy.com/
經常使用 CSS 樣式名稱
這裏引用一下掘金做者 冷石Boy 的 css 樣式名稱
包裹類： container, wrapper, outer, inner, box, header, footer, main, content, aside, page, section, block
狀態類： primary, secondary, success, danger, warning, info, error, Link, light, dark, disabled, active, checked, loading
尺寸類： large, middle, small, bigger, smaller
組件類： card, list, picture, carousel, swiper, menu, navs, badge, hint, modal, dialog
位置類： first, last, current, prev, next, forward, back
文本類： title, desc, content, date, author, category,label,tag
人物類： avatar, name, age, post, intro
取名推薦工具
固然對於命名有困難選擇症的朋友來講，能夠推薦大家一個意想不到的網站 —— Codelf (https://unbug.github.io/codelf)，一個幫你搜索 Github、GitLab 等網站中，你想查找的內容的不一樣命名。
而且這個網站支持 JavaScript、CSS、HTML、Java 等多種語言的搜索，能夠方便的過濾不須要的搜索類型。
Hover 搜索詞後的操做，Search 會再以當前選詞進行一次搜索，Repo 能夠跳轉這個詞語的出處項目，Copy 固然就不說了，有興趣的朋友均可以嘗試一下。
總結
命名其實並不麻煩，遵循一些定好的規則規範，或者本身給本身定義好這個規範，而後進行直白、有意義的命名，那麼以後的命名就只會成爲你的一種習慣，而再也不是困擾你的難題，也但願你們能夠分享一些本身的命名規範或者技巧，共同討論下吧。
參考文獻
-
故宮命名法：https://juejin.cn/post/6844903913892610061 -
如何代碼命名：https://www.cyningsun.com/07-04-2020/how-to-naming-things.html
插個題外話
掘金 2020 年度做者榜單火熱打榜中！你的支持是咱們最大的動力！小編已被要求今日不增長 2000 票會被祭天（求保護~~），我很急，你們速度一點，掃描二維碼，認準團隊榜單第一名政採雲前端團隊
看完兩件事
若是你以爲這篇內容對你挺有啓發，我想邀請你幫我兩件小事
1.點個「在看」，讓更多人也能看到這篇內容（點了「在看」，bug -1 😊）
招賢納士
政採雲前端團隊（ZooTeam），一個年輕富有激情和創造力的前端團隊，隸屬於政採雲產品研發部，Base 在風景如畫的杭州。團隊現有 40 餘個前端小夥伴，平均年齡 27 歲，近 3 成是全棧工程師，妥妥的青年風暴團。成員構成既有來自於阿里、網易的「老」兵，也有浙大、中科大、杭電等校的應屆新人。團隊在平常的業務對接以外，還在物料體系、工程平臺、搭建平臺、性能體驗、雲端應用、數據分析及可視化等方向進行技術探索和實戰，推進並落地了一系列的內部技術產品，持續探索前端技術體系的新邊界。
若是你想改變一直被事折騰，但願開始能折騰事；若是你想改變一直被告誡須要多些想法，卻無從破局；若是你想改變你有能力去作成那個結果，卻不須要你；若是你想改變你想作成的事須要一個團隊去支撐，但沒你帶人的位置；若是你想改變既定的節奏，將會是「5 年工做時間 3 年工做經驗」；若是你想改變原本悟性不錯，但老是有那一層窗戶紙的模糊… 若是你相信相信的力量，相信平凡人能成就非凡事，相信能遇到更好的本身。若是你但願參與到隨着業務騰飛的過程，親手推進一個有着深刻的業務理解、完善的技術體系、技術創造價值、影響力外溢的前端團隊的成長曆程，我以爲咱們該聊聊。任什麼時候間，等着你寫點什麼，發給 ZooTeam@cai-inc.com
本文分享自微信公衆號 - 政採雲前端團隊（Zoo-Team）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。