摘要：最近在知乎上看到這個(gè)作為程序員，有沒(méi)有讓你感到既無(wú)語(yǔ)又崩潰的程序命名。今天，也分享下最近自己在使用的命名習(xí)慣，當(dāng)然只是個(gè)人習(xí)慣。但是兩個(gè)函數(shù)的命名，一個(gè)是，另一個(gè)是。關(guān)于的命名規(guī)范，應(yīng)該很多人都是習(xí)慣用大駝峰命名。

把一件平凡的事情做好，很平凡。把一件平凡的事情堅(jiān)持的做好，很不平凡。

如果說(shuō)計(jì)算機(jī)科學(xué)只存在兩個(gè)難題：緩存失效和命名。那么我就覺(jué)得命名的難點(diǎn)只有兩個(gè)：詞匯量和堅(jiān)持貫徹執(zhí)行制定的規(guī)范。

最近在知乎上看到這個(gè)：作為程序員，有沒(méi)有讓你感到既無(wú)語(yǔ)又崩潰的程序命名？。頓時(shí)感慨萬(wàn)千，因?yàn)槊麑?duì)于程序員來(lái)說(shuō)是就是一個(gè)難題，有時(shí)候因?yàn)槊赡軙?huì)引起別人的誤導(dǎo)，疑惑等，對(duì)開發(fā)效率，項(xiàng)目的質(zhì)量影響可大可小。今天，也分享下最近自己在使用的命名習(xí)慣，當(dāng)然只是個(gè)人習(xí)慣。更希望能在評(píng)論區(qū)看到大家推薦的命名方式，互相學(xué)習(xí)，交流。

關(guān)于整篇內(nèi)容，主要提及兩個(gè)：
1.如何寫出讓別人容易讀懂的命名
2.針對(duì)不同的對(duì)象，使用對(duì)象命名的格式

首先，先盤點(diǎn)下有哪些命名的一些方式是很難讓別人讀懂的。這些情況，大家看到就應(yīng)該在開發(fā)上盡量避免下。

舉個(gè)例子

//提交表單（把 Form 寫成了 From ）
submitFrom(){...}

之前寫文章也有說(shuō)過(guò)，單詞拼寫正確可以說(shuō)是一個(gè)底線了。如果單詞拼寫錯(cuò)誤，比如 form 和 from 都是正確的單詞，但完全不一樣的意思，如果把 form 寫成 from ，以后讀代碼的人（也可能是你自己），很有可能會(huì)懵逼。

單詞拼寫錯(cuò)誤會(huì)誤導(dǎo)別人，中英文混用這個(gè)命名方式就可以說(shuō)讓人云里霧里的感覺(jué)，不會(huì)誤導(dǎo)，只會(huì)看不懂。

比如下面

let chanpinList=[];

這個(gè)變量名，一開始不知道是什么，注釋也沒(méi)有，完全懵逼。后來(lái)看了需求，才知道這個(gè)的意思是：產(chǎn)品列表。

這個(gè)情況相信大家都會(huì)遇到過(guò)，比如頁(yè)面上有幾個(gè)按鈕，有人命名成 btn1，btn2，btn3，btn4...。或者 btnA，btnB，btnC，btnD。這樣的命名看似簡(jiǎn)單，但實(shí)際上從這些命名里面讀取不到任何信息，以后會(huì)可能會(huì)痛苦些。

這個(gè)可以說(shuō)沒(méi)那么可恨，但是看著就別扭，比如表示評(píng)論列表，有地方這樣命名：comments，另一個(gè)地方這樣命名： comment-list，還有這樣命名： commentList。幾種規(guī)范混在一起，就感覺(jué)不規(guī)范了。

還用一種雖然一般不會(huì)出現(xiàn)的情況，也遇見(jiàn)了。比如一個(gè)地方有添加供應(yīng)商的按鈕，命名是：addSupplier 。在另一個(gè)地方也有相同的功能按鈕，完全一樣，結(jié)果命名是：addSupplierInfo 。當(dāng)時(shí)就以為這兩個(gè)不是同一個(gè)功能，造成了誤會(huì)。

有些名詞，被中國(guó)人創(chuàng)造出來(lái)（淘寶-taobao，微博-weibo），沒(méi)有英文翻譯的。就可以用中文拼音命名，其他的都建議用英文。

但是偏偏有時(shí)候就算有英文的單詞，有些人還是用中文拼音命名，比如一個(gè)文章列表，很多人就是沒(méi)用 articleList，直接寫 wenzhangliebiao。但是看的時(shí)候，一定會(huì)懵逼一會(huì)。

簡(jiǎn)介雖然可以讓命名看著更加的簡(jiǎn)潔，但是有時(shí)卻會(huì)遇上強(qiáng)制簡(jiǎn)寫的命名，比如一個(gè)函數(shù)是提交用戶評(píng)論信息的功能。原本以為是：handleCommentSubmit/submitComment/publishComment。結(jié)果后來(lái)一看--tjyhpl。強(qiáng)制簡(jiǎn)寫還是用拼音的簡(jiǎn)寫，后來(lái)讓他改一下，改成了ac。后來(lái)一問(wèn)才知道他想表達(dá)的意思是 addComment ，當(dāng)時(shí)差點(diǎn)動(dòng)手了。

這個(gè)情況不算惡劣，只算是一種規(guī)范吧，之前有分別有兩個(gè)操作函數(shù)，一個(gè)是下載全部訂單數(shù)據(jù)，一個(gè)是下載當(dāng)前訂單數(shù)據(jù)。但是兩個(gè)函數(shù)的命名，一個(gè)是downloadOrderData，另一個(gè)是downloadOrder。這樣也產(chǎn)生了一點(diǎn)懵逼感。

面對(duì)這樣的情況，建議還是區(qū)分下單復(fù)數(shù)，downloadOrder，downloadOrderAll/downloadOrderList。區(qū)分了單復(fù)數(shù)的命名，如果有返回值，也可以讓別人大概知道，單數(shù)可能就是返回單個(gè)記錄，復(fù)數(shù)可能返回一個(gè)數(shù)組。

這個(gè)情況同上，不算是惡劣，只能算是不規(guī)范。比如：分別有兩個(gè)操作函數(shù)一個(gè)是顯示彈窗，一個(gè)是關(guān)閉彈窗。結(jié)果命名上面，一個(gè)是 showEditDialog 。另一個(gè)是 closeEditDialog 。

上面的案例，show 和 close ，一個(gè)是顯示，一個(gè)是關(guān)閉，顯然不是正反義詞。應(yīng)該出現(xiàn)的姿勢(shì)是，showEditDialog 和 hideEditDialog ，或者 openEditDialog 和 closeEditDialog

還有其它的搞笑命名，在知乎上面看到的情況，別人遇到的情況。大家移步到知乎吧，這個(gè)不重復(fù)太多。

作為程序員，有沒(méi)有讓你感到既無(wú)語(yǔ)又崩潰的程序命名？。

說(shuō)完了命名第一個(gè)，命名單詞應(yīng)該正確的書寫之后。再來(lái)說(shuō)下命名的相關(guān)格式在說(shuō)自己的命名實(shí)例之前，先說(shuō)下不同的命名對(duì)象，命名方式是不一樣的。具體如下：

在說(shuō)命名 HTML 命名之前，先說(shuō)下布局的三個(gè)概念：模塊( module )和元件( unit )

模塊：各種常見(jiàn)的網(wǎng)頁(yè)內(nèi)容模塊，通?？梢灾貜?fù)使用的較大的整體，比如導(dǎo)航、菜單、幻燈、圖文列表等。命名前面建議帶有 m-

元件：各種常見(jiàn)的網(wǎng)頁(yè)內(nèi)容元件，比如按鈕、標(biāo)題、輸入框等。命名前面建議帶有 u-

兩者關(guān)系，模塊包含元件，元件組成模塊。

小小實(shí)例

看到上面的一個(gè)小彈窗。整個(gè)彈窗，當(dāng)成一個(gè)模塊。可以把標(biāo)題，提示內(nèi)容，按鈕當(dāng)做元件。HTML 代碼就如下，CSS , JS 代碼就不貼了。模塊就帶 m- ，元件就帶 u-

    

        

            
提示2
            
這里是提示內(nèi)容2
        
        

            確定
        
    

至于這樣的寫法有什么優(yōu)劣，注意事項(xiàng)，這里就不展開講了，以后再寫文章。

在js命名里面，應(yīng)該只有四種命名方式：小駝峰(productList)，大駝峰(ProductList)，大寫字符，下劃線分割（PRODUCT_LIST），下劃線開頭+小駝峰(_productList)

在js寫法里面，小駝峰命名應(yīng)該是最多的一種。變量，函數(shù)一般而言都是使用小駝峰命名。

//登錄處理函數(shù)
let handleLogin=function(){}

在es6之前，js還沒(méi)有class的概念，但是也組織不了開發(fā)者模擬class。現(xiàn)在有了class，自然而然，class的命名規(guī)范就更離不開了。關(guān)于class的命名規(guī)范，應(yīng)該很多人都是習(xí)慣用大駝峰命名。

//創(chuàng)建一個(gè)類
class Person{
    //...
}

常量建議還是使用大寫字符+下劃線命名。

//配置最大金額
const PRICE_MAX=10000;

私有變量相對(duì)于外面作用域而言，為了區(qū)分變量是公用的，還是私有的。建議命名上面就做下區(qū)分，私有變量建議使用下劃線開頭+小駝峰命名方式。

let myObj={
    name:"守候",
    setName(){
        //保存當(dāng)前的this
        let _this=this;
        setTimeOut(function(){
            alert(_this.name)
        },1000)
    }
}

函數(shù)命名，一般都是動(dòng)詞開頭。

如果函數(shù)是為了獲取值(函數(shù)最后會(huì)返回一個(gè)值的)，函數(shù)前面建議帶有g(shù)et。

//根據(jù) ID 獲取用戶信息
function getUserInfo(id){
    
}

如果函數(shù)是為了設(shè)置值(函數(shù)最后會(huì)返回一個(gè)值的)，函數(shù)執(zhí)行就是為了給某一個(gè)變量賦值，函數(shù)前面建議帶有set。

//設(shè)置用戶信息
function setUserInfo(){
    
}

如果函數(shù)是為了處理一些操作，比如登錄，注冊(cè)，渲染列表等。那么就建議命名前面帶有handle。

//分頁(yè)操作
handleChangeCurrent(val){
    
}
//注冊(cè)操作
handleRegister(){
    
}

這個(gè)處理動(dòng)作，有些開發(fā)者也是習(xí)慣直接以動(dòng)作開始。openDialog，closeDialog等。

統(tǒng)一小駝峰命名法。

如下例子：

如果發(fā)現(xiàn)名稱過(guò)長(zhǎng)，可以在團(tuán)隊(duì)約定好簡(jiǎn)寫格式：比如 product 簡(jiǎn)寫成 pro 。

如果是通用性質(zhì)的圖片，例如LOGO，菜單，側(cè)邊欄，背景等，就直接使用小寫字母命名。比如：logo.jpg ，menu.jpg，aside.jpg，bg.jpg。

如果不是通用的圖片，就建議根據(jù)類別-模塊-功能的格式。使用小寫字母，‘-’或者‘_’分割，如下例子：

一些前端書寫規(guī)范建議

關(guān)于團(tuán)隊(duì)合作的css命名規(guī)范

關(guān)于命名，很簡(jiǎn)單，也很難。也是困擾著很多的開發(fā)者，包括我。該文章的命名方式，也是我在用的一種個(gè)人命名方式，希望能讓大家有所收獲。當(dāng)然其中還有很多的瑕疵，希望大家多多指點(diǎn)，或者推薦下自己建議的命名方式。

關(guān)于命名的規(guī)范，每個(gè)公司都有自己的編碼規(guī)范，只是很少公司能認(rèn)真貫徹執(zhí)行自己的規(guī)范，從而導(dǎo)致命名錯(cuò)亂。所以命名的難點(diǎn)，我不認(rèn)為是命名本身有難度，難度在于在項(xiàng)目上，面對(duì)各種需要命名的對(duì)象，堅(jiān)持使用一套命名格式，正確的命每一個(gè)名。

-------------------------華麗的分割線--------------------

想了解更多，和我交流，內(nèi)推職位，請(qǐng)?zhí)砑游椅⑿?。或者關(guān)注我的微信公眾號(hào)：守候書閣