命名技巧心得

宗旨

一個命名提供的信息量越多，就是越好的命名。

最容易的事

聲明一個變量，是編程裏最簡單的事了。

在學習編程之初，先要會的就是聲明一個變量。

int a = 1;
複製代碼

最困難的事

命名又是咱們工做中最有難度的事。

隨着咱們技術能力的提升，作的項目也愈來愈大，業務愈來愈複雜。命名稍微不注意，就變成一堆無心義或者誤導咱們的字符串。

之因此說命名困難，個人想法是命名不單是想一個單詞就ok。須要更多的理解業務，理解咱們使用的技術，才能作到最貼切的命名。

信息量

回到咱們的宗旨，來看看命名都會給咱們提供哪些信息量。

例1

var username = '卡哇伊';
複製代碼

這段代碼中有個變量username，它爲咱們提供了一個信息。

1. 這是一個表明用戶名的字段。

例2

var _username = '卡哇伊';
複製代碼

這段代碼是有個變量_username，它爲咱們提供了兩個信息。

1. 這是一個表明用戶名的字段。
2. 這是一個私有變量。咱們把下劃線開頭的變量，稱爲私有變量。只有類內部能夠訪問。

例子3

class User {
    constructor() {
        this._name = '卡哇伊';
    }
    
    getName() {
        return this._name;
    }
    
    setName(val) {
        this._name = val;
    }
}
複製代碼

User命名的信息

1. 這是一個類。
2. 用戶的類。
3. 爲內部的變量提供上下文，因此用戶名能夠只寫成_name，表明User的_name。若是還須要一個用戶年齡的字段，能夠只寫成_age。

getName的信息

1. 這是一個方法，由動詞+名詞組成。咱們用動詞或者動詞+名詞命名一個方法。由於方法自己就表明某種動做，因此這樣命名很貼切。而且和類的字段（名詞）作了有效的區分。這樣你在其餘地方使用user.get***。你就知道這是調用了user的一個方法。user.hand就是使用了user的一個字段。
2. 拿到用戶名。

讀到這裏，我想你大概知道我要說的什麼意思了。咱們經過命名的格式，用開頭有下劃線表明私有變量，用首字母大寫表明是一個類。區分不一樣類型的成員，達到讓代碼擁有更多信息量的目的。

那麼，重點就是掌握一套這樣的命名規則，並嚴格貫徹這套規則。

工做中的實踐

這裏拿React寫一個頁面做爲例子 首先我要新建一個Pages文件夾，而後新建一個ProductListPage文件夾，在裏面創建index.js文件，代碼以下：

class ProductListPage extends Component {

    constructor(props) {
        this.state = {
            productList:[],
            categroyOptions:[],
        }
    }
    
    componentDidMount() { ... }
    
    
    async requestProductList() { ... }
    
    async requestCategroyOptions() { ... }
    
    
    renderProductList() {
        const { productList } = this.state;
        
        return productList.map(product => { ... });
    }
    
    renderHeader() { ... }

    render() { ... }
}
複製代碼

Pages文件夾：

1. 頁面文件夾，爲其下的文件提供上下文，我是一個放置頁面文件的文件夾。
2. 代表我在項目的的位置，項目中還能夠定義其餘類別的文件夾，components文件夾，reducers文件夾，共同造成項目結構。

ProductListPage：

1. ProductListPage表明我要寫一個產品列表相關的頁面。
2. Page尾綴與Pages文件夾呼應。在項目中有特殊地位的文件，加尾綴是頗有用處的，好比你的代碼中出現一個productListReducer變量，你就知道它來自Redcer這個特定模塊。

componentDidMount:

1. 這裏着重說一下react的聲明週期方法，我認爲這個命名是比vue的略好一點的。==由於越是系統級別的命名，越是要詳細一點==。由於系統級別的方法，用的場景多，重名的概率就大。好比vue的created生命週期方法，一個新手不知道這個方法，在寫一個私有方法的時候，剛好也是建立某事物的含義，就用了creacted命名，就形成了重名。
2. componentDidMount的component又與組件呼應。明確的告訴咱們這是組件的mount。
3. 引申出一條規則是：越局部的變量能夠越短小。它能夠充分的利用上下文解釋本身。

productList：

1. 這個變量與頁面名字同名，我喜歡用這種方式告訴本身，這個變量是這個頁面的主角。另外List尾綴也有強調這是個重要數據的意思，配角的列表數據我都喜歡加s，好比categroyOptions。這樣利用List和s區分主次關係。
2. 在列表變量進行循環的時候，循環體中就能夠用product

requestProductList：

1. 請求產品列表。
2. request是一個關鍵動詞，我賦予了它特別的含義，就是須要稍微花點時間才能取到的值，與get動詞對應。

renderProductList：

1. 渲染產品列表
2. render是一個關鍵動詞，是react的擁有特殊含義的詞，渲染頁面。

嗯，每一個命名都滿滿的信息量，咱們就獲得了易讀又工整的代碼。

規則的破壞

值得注意的是，命名是件須要自律和習慣的事。好比某一天增長了一個產品包裝頁，我寫成了goodsPackingPage。這樣‘產品’這個有特殊業務含義的字段在項目中有了兩個命名，product和goods，這就形成了必定的混亂。

我見過這樣一個單文件，有2000多行的代碼，一樣表明品類，結果有三個單詞type,catagory,class。起初我覺得是不一樣的意思，這就形成了閱讀的困難。你的代碼越複雜，命名不當形成的問題越嚴重。

因此咱們在寫代碼時，創建的命名秩序，就不能破壞它。一旦破壞，本來能夠傳達的信息，便再也不可信。好比新寫的私有字段不如下劃線開頭。那麼之後在函數中看到變量，就不能根據是否已下劃線開頭，判斷它是不是私有變量了。

結束語

判斷一個命名是否糟糕，就是看它有沒有傳達信息。更糟糕的是，它傳達錯誤的信息。

好的命名就是能傳達更多信息。依靠的是你創建的命名秩序。

若是你對整潔代碼頗有興趣。推薦《代碼整潔之道》這本書。裏面有更多詳細的關於命名的技巧知識。