一.變量命名風格

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

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

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

String userName;

2）靜態(tài)成員變量、枚舉值、常量

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

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;
  }
}

二.變量命名最高境界

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

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

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

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

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循環(huán)，不過還是不太推薦在for循環(huán)中使用單字母變量(用pos、index比for循環(huán)的i、j、k要好很多)。

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

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

　　咋一看這個函數(shù)參數(shù)感覺挺清晰，但是一細看，b是什么？d又是什么？如果我要用這個函數(shù)，該怎么傳參？估計大部人是一臉懵逼狀，只能進去看實際的函數(shù)實現(xiàn)才知道b是圓錐體半徑，d是圓錐體高度；

　　那么怎么優(yōu)化這段代碼命名呢？其實很簡單，稍微細化一下變量含義，讓變量名自己去表達實際意圖：

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

3）變量命名前后用詞需統(tǒng)一

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

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

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

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

　　一般可采取兩種方式：

使用復數(shù)s結尾

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

用集合類型作為后綴

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

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

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

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

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

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

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的時候又代表什么含義？是醫(yī)生的值班/在崗狀態(tài)、還是醫(yī)生的身體狀態(tài)？估計讀者的內心是崩潰的。

　　如果優(yōu)化成下面這種形式：

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

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

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家。