結束了名詞篇後，考慮了很久，決定還是先說代名詞。
什麼是代名詞？就是代替前面說過的名詞，但在軟體開發裡的代名詞是什麼？就是把類別實體化的物件或者變數。例如:

    var message string = "Hello World!"

(正在學golang,還是改不了加分號的習慣)

類別設計了那麼久，目的當然是為了在開發時可以使用，因此做出來的類別必定會在系統裡出現一次以上。既然類別都有命名規則，變數或參數當然也會有相對應的命名規則。

命名規則

變數相對於類別的規則比較單純且統一，大多都建議或推薦camelCase，少數會用kebab-case但會有些限制。所以如果有一個類別叫UserAccount，那在使用這個類別時就會下成

    UserAccount userAccount = new UserAccount();

即然這麼簡單，那還有什麼要說的?

叔叔的溫馨提醒

Uncle Bob，軟體工程的好長輩，在他的Clean Code一書提到了必需要注意的要點：

變數本身就要可以看出它的用途

如果一個變數本身寫成這樣

    int depositAmount = userAccount.getDepositAmount();

和寫成這樣

    //Get user's deposit amount
    int amt = userAccount.getDepositAmount();

那一個會比較好呢?
(註解派覺得溫馨?)

不要加入誤導資訊

這點我覺得非常重要，特別是let啊,var啊,或者類似的語法讓開發人員可以省略宣告式的方法開始流行後。
例如在Javascript裡看到這麼一個變數宣告

    var userHistoryList = user.GetAccount();

怎麼看都會覺得他是一個List吧！我認為var跟let的出現並沒有問題，但必需要在開發人員可以立即辨視出它的用途及型態的前題下，如果會造成誤導，還是用完整型態比較恰當。

命名上在做意義上的區隔。

不要這樣命名

    User userA = new User("John Doe");
    User userB = new User("Jenny Doe");

在[名詞四] 類別的命名原則時提過，類別的命名是很泛指，很一般的，直到被實體化時才會讓它特指某個物件。因此在變數命名上，應當將它的真實意義名稱帶進去。

Don't Be Cute

雖然我自己有時候也會想在程式裡帶入一些創意，例如把修改的範圍命名為"AreaOfEffect"，或者用拼音或者擬人化某些類別，但這些太過Nerdy或者可能冒犯到其他人的程式，不但降低了可讀性，也有可能會讓團隊陷入危機。
（對，我在說還願）

用一個字來描述一個概念

英文同義詞是很多的，但軟體開發不是寫作文，不需要一直想各種不同的名詞來描述同一種東西，保持一致性的說明同一類東西。

做為類別的應用，他的學問其實很多，特別是字詞的使用如何才能到點到位，這除了考驗一個開發人員對相關問題了解程度外，也考驗對開發的用心程度。雖然大多數的情況開發人員其實不用考慮命名的內容，但其實如果深究的話，命名其實是也算是資深開發人員的能力之一。

我算了一下，覺得有可能會有幾天是空堂QQ，雖然還是可以努力補滿但有點為寫而寫覺得太無謂了，因此想挑幾天說一下英文履歷的寫作心得。
（畢竟也花了三個月的時間在修履歷給老外看）
有興趣的記得訂閱這個系列，也分享給你的朋友一起來討論軟體工程師的英文課吧！