這是第 87 篇不摻水的原創,想獲取更多原創好文,請搜索公衆號關注咱們吧~ 本文首發於政採雲前端博客:編寫高質量可維護的代碼:優雅命名css
俗話說得好,萬事開頭難。而對於前端 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
因此在命名的時候,須要的就是直白、完備、有意義,讓別人經過命名就能瞭解到這個名稱(不管是變量、方法或者是樣式名)背後的的含義,這樣的命名就是高效的、易懂的。sass
習慣使用業界習慣的命名標識,或者是約定俗成的書寫習慣。markdown
用 id
當作數據標識命名,而不是 identifier
app
例如布爾值命名類型,一般只有兩個值類型:真,假,根據不一樣的使用場景,也能夠有一些經常使用的命名方式
// 可見、狀態等,可用 is+動詞/形容詞的方式
const isVisible;
const isLoading;
// 配置,選項等類型,能夠用 withXxx、hasXxx 來標識是否有某個屬性等,enableXxx 來表示是否開啓配置
const withTab;
const hasPlan;
const enableFilter;
複製代碼
// 數據獲取方法
function getUserInfo(){};
function fetchSearchList(){};
// 須要根據一些屬性去獲取數據
function getGoodsById(){};
function queryUserByName(){};
// 刪除數據
function deleteUser(){};
function removeGoodsItem(){};
// 格式化數據
function formatDate(){};
function sortByDesc(){}
複製代碼
團隊若是用統一的命名規範,那就必定要遵照,例如文件名的命名是大寫字母開頭的駝峯寫法,那你的命名就不能再修改成其餘方式,在規範建立之初或者修訂時能夠提出修改意見並進行討論,但若是已經確立的,就不要再。去自由的破壞規範。
固然也可使用一些輔助手段幫助約束代碼中的命名校驗,**例如在 Eslint 配置中加入 id-match
或者 camelcase
,前者能夠直接經過正則配置本身須要的命名規範,後者則是直接採用了駝峯命名的規範約束 **。
這裏也舉例介紹一下在 VsCode
中 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;
複製代碼
// good
const userInfo;
const userAddressList;
const currentDate;
複製代碼
_
分割// good
const ITEM_LIST;
const PAGE_ITEM_LIST;
const DEFAULT_CONFIG;
複製代碼
handlexxxxChange
,handlexxxxShow
,而好比數據獲取能夠用 get,fetch 這類// 小駝峯命名
function getUserInfo(){};
function addSuplierInfo(){};
// 添加一些操做類的輔助命名
function handleUserInfoChange(){};
function handleTitleClick(){};
function fetchPageData(){};
複製代碼
export class CommonLogo;
export class CartCenter;
複製代碼
BEM
是一種命名 CSS 樣式的命名方法和規範,全稱 Block
(塊)、 Elemen
t(元素)、 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 命名規範的網站,有興趣的能夠去看看:
這裏引用一下掘金做者 冷石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,一個幫你搜索 Github
、GitLab
等網站中,你想查找的內容的不一樣命名。
而且這個網站支持 JavaScript
、CSS
、HTML
,Java
等多種語言的搜索,能夠方便的過濾不須要的搜索類型。
Hover 搜索詞後的操做,Search 會再以當前選詞進行一次搜索,Repo 能夠跳轉這個詞語的出處項目,Copy 固然就不說了,有興趣的朋友均可以嘗試一下。
命名其實並不麻煩,遵循一些定好的規則規範,或者本身給本身定義好這個規範,而後進行直白、有意義的命名,那麼以後的命名就只會成爲你的一種習慣,而再也不是困擾你的難題,也但願你們能夠分享一些本身的命名規範或者技巧,共同討論下吧。
【Flutter 技能篇】你不得不會的狀態管理 Provider
政採雲前端團隊(ZooTeam),一個年輕富有激情和創造力的前端團隊,隸屬於政採雲產品研發部,Base 在風景如畫的杭州。團隊現有 40 餘個前端小夥伴,平均年齡 27 歲,近 3 成是全棧工程師,妥妥的青年風暴團。成員構成既有來自於阿里、網易的「老」兵,也有浙大、中科大、杭電等校的應屆新人。團隊在平常的業務對接以外,還在物料體系、工程平臺、搭建平臺、性能體驗、雲端應用、數據分析及可視化等方向進行技術探索和實戰,推進並落地了一系列的內部技術產品,持續探索前端技術體系的新邊界。
若是你想改變一直被事折騰,但願開始能折騰事;若是你想改變一直被告誡須要多些想法,卻無從破局;若是你想改變你有能力去作成那個結果,卻不須要你;若是你想改變你想作成的事須要一個團隊去支撐,但沒你帶人的位置;若是你想改變既定的節奏,將會是「5 年工做時間 3 年工做經驗」;若是你想改變原本悟性不錯,但老是有那一層窗戶紙的模糊… 若是你相信相信的力量,相信平凡人能成就非凡事,相信能遇到更好的本身。若是你但願參與到隨着業務騰飛的過程,親手推進一個有着深刻的業務理解、完善的技術體系、技術創造價值、影響力外溢的前端團隊的成長曆程,我以爲咱們該聊聊。任什麼時候間,等着你寫點什麼,發給 ZooTeam@cai-inc.com
掘金2020年度做者榜單火熱打榜中!你的支持是咱們最大的動力!小編已被要求今日不增長兩千票會被祭天(求保護~)
每點一次是一票,天天能夠點不少次喲~