工程實踐：如何給變量取一個好的名字

　　在上一篇文章中跟大家分享了關于函數命名的一些實踐心得，今天我們繼續命名這個話題，來講一講如何對變量命名。

　　以下是本文的目錄大綱：

　　一. 變量命名風格

　　二. 變量命名最高境界

　　三. 變量命名最佳實踐

　　若有不正之處請多多諒解，并歡迎批評指正。

　　請尊重作者勞動成果，轉載請標明原文鏈接：

    　http://www.rzrgm.cn/dolphin0520/p/10639167.html

一.變量命名風格

　　變量命名風格通常會根據不同的變量類型來區分，以Java語言為例，根據變量類型不同有兩種命名風格：

1）類成員變量、局部變量

　　類成員變量、局部變量通常采用駝峰命名風格，如下：

String userName;

2）靜態成員變量、枚舉值、常量

　　靜態成員變量、枚舉值、常量通常采用所有字母大寫、多個單詞以英文下劃線連接，如：

public static final int MAX_YEARS = 25;
?
// 建議枚舉類都以Enum結尾
enum ColorEnum {
    RED(0, "紅色"),
    YELLOW(1, "黃色"),
    GREEN(2, "綠色"),
    WHITE(3, "白色"),
    BLACK(4, "黑色");
    private int code;
    private String name;
?
    Color(int code, String name) {
        this.code = code;
        this.name = name;
    }
}

二.變量命名最高境界

　　在函數命名那篇中我們說的函數命名最高境界是見字如面，那么對于變量命名來說，最高境界是什么呢？ 我認為是：自解釋，即"代碼即注釋"。

　　為什么這么說呢，因為通常來說一個函數是會有函數注釋的，即使函數名字取的不好，如果注釋寫的比較清楚，對于后續維護人員來說也是了解函數具體功能的一種方式。

　　而變量則不同，在一個工程里面，變量的數量遠遠大于函數的數量，所以不太可能對于每個變量都去寫注釋，所以如果一個工程的變量命名很糟糕，那么對于后續維護人員來說將是毀滅性的打擊，因為每讀到一個變量，可能就需要去猜測變量的含義，我想沒有哪個人愿意讀到這樣的代碼，永遠記住一點："代碼是寫給人看的，不是寫給機器看的"。

　　譬如下面這段代碼的命名就非常糟糕：

ppn = (cpn > 1) ? (cpn - 1) : cpn;
npn = (cpn < tpn) ? (cpn + 1) : tpn;
?
p = new Page(ppn, cpn, npn, tpn);

　　上面這段代碼估計只有原作者清楚地知道各個變量的含義是啥了，

　　如果修改為下面這種寫法，可讀性會好很多，并且一目了然，很容易知道其大概意圖是計算分頁信息：

prePageNum = (curPageNum > 1) ? (curPageNum - 1) : curPageNum;
nextPageNum = (curPageNum < totalPageNum) ? (curPageNum + 1) : totalPageNum;
?
page = new Page(prePageNum, curPageNum, nextPageNum, totalPageNum);

三.變量命名最佳實踐

1）采用名詞或者形容詞來命名變量

　　變量一般情況下建議使用名詞、名字組合或者形容詞，因為變量一般形容的是一種事物或者事物的屬性，所以用名詞或者名詞組合更容易讓人理解，而形容詞一般用于bool類型的變量。

2）避免使用單字母變量，盡量細化變量含義

　　在程序中，盡量避免使用單字母變量，唯一可以接受使用單字母變量的場景只有for循環，不過還是不太推薦在for循環中使用單字母變量(用pos、index比for循環的i、j、k要好很多)。

　　舉個例子，比如下面這行代碼：

double calConeVolume(double b, double d) {
  return Math.PI * b * b * d / 3;
}

double calConeVolume(double radius, double height) {
  return Math.PI * radius * radius * height / 3;
}

3）變量命名前后用詞需統一

　　在同一個工程或者一個場景下，變量命名風格需前后統一，比如total和sum都能表示總計的意思，那么所有需要用到"總計"含義的地方要么全部使用total、要么全部使用sum。

　　保持前后命名風格統一是保證工程代碼良好可讀性的關鍵保證。

4）集合變量用類型或者復數s作為后綴

　　在java中，有很多集合，比如List、Map、Set等，那么集合變量該怎么命名呢？

　　一般可采取兩種方式：

• 使用復數s結尾

List<Student> students = new ArrayList<>();

• 用集合類型作為后綴

List<Student> studentList = new ArrayList<>();

　　上面兩種方式均可，沒有比較明顯的偏好，根據實際場景決定。第一種方式相對更簡潔，第二種在局部作用域里面有多種相關的集合變量時區分度更大，比如：

List<Student> studentList = new ArrayList<>();
Map<Long, Student> studentMap = Maps.newHashMap();
?
for (Student stu : studentList) {
  studentMap.put(stu.getId, stu);
}

　　我的建議是如果局部作用域只有一種類型的集合，那么推薦使用復數形式；如果局部作用域有多個相關的集合類型，那么推薦用類型結尾。

5）禁止使用is作為bool類型的類成員變量前置

　　在java中，禁止用is作為bool類型的類成員變量的前綴，因為is作為前綴會導致序列化/反序列出現問題，阿里的java代碼規范中也明確提到了這一點，所以在寫代碼的時候最好還是遵守公認的規范，不然哪天說不定就踩坑了。

6）盡量避免使用縮寫進行命名

　　有些時候，變量名可能有點長，不利于代碼可讀性，因此很多時候在寫代碼的時候喜歡用縮寫來命名，但這個不是一個好的習慣，除非使用的縮寫是大家都會使用的約定俗稱的縮寫。

　　比如下面這個命名：

int averageStudentAge;  =>  int avgStudentAge;

　　因為avg大家都知道是average的縮寫，所以這么寫問題不大，不會引起歧義；

　　但是下面這種縮寫命名：

res
tmp
cnt

　　就不是好的縮寫命名，因為不同的人閱讀可能會有不同的理解：

res => response、resource、result
tmp => temporary、template
cnt => count、content、context

　　附上一些約定俗稱的縮寫：

7）拋棄掉flag變量

　　國內一些早期的教材上，到處充斥著各種flag風格的變量，這種命名方式對于大型工程簡直就是噩夢，比如：

int flag = getDoctorFlag(doctorId);
if (flag == 1) {
  //....
}

　　看到這段代碼，讀者會有疑問flag變量的含義是什么？flag值為1的時候又代表什么含義？是醫生的值班/在崗狀態、還是醫生的身體狀態？估計讀者的內心是崩潰的。

　　如果優化成下面這種形式：

DutyStatus doctorDutyStatus = getDoctorDutyStatus(doctorId);
if (doctorDutyStatus == DutyStatus.ONLINE) {
  // ...
}

　　就比上面的形式清晰多了，很容易看出來判斷的是醫生的值班/在崗狀態。