閱讀《代碼整潔之道》有兩種原因，第一種：你是個程序員；第二，你想成為更好的程序員。
讀完后，你能獲得如下技能：
- 知道更多關于代碼的事兒
- 辨別好代碼和糟糕代碼的差異
- 學會如何寫出好代碼
- 學會如何將糟糕代碼改成好代碼
Later equals never. 有些事兒現在不做以后都不會做了。
程序員基礎價值謎題
以前混亂的代碼拖了自己后腿，但開發者背負著期限的壓力，只好繼續制造混亂。而制作混亂無助于趕上期限。
趕上期限的唯一辦法：始終保持代碼的整潔。
寫整潔代碼就像是繪畫。多數人知道一幅畫是好是壞，但能分辨優劣并不表示懂得繪畫，能分辨代碼優劣的人也不意味著會寫整潔代碼。
寫整潔代碼需要遵循大量的小技巧，貫徹刻苦習得的“整潔感”。這種“代碼感”就是關鍵所在。
什么是整潔代碼
整潔的代碼只做好一件事。簡潔，優雅。
每個函數、每個類、每個模塊都全神貫注于一事，不受四周細節的干擾和污染。
有意義的命名
變量、函數、參數、類、包、文件。有很多地方需要命名。怎么命名才能簡潔明了？
1. 名副其實
說起來簡單，但這是一個很嚴肅的問題。選個好名字要花時間，但省下來的時間比花掉的多。一旦有好的命名，就換掉舊的。
- 如果名稱需要注釋來補充，那么說明名字沒取好。(不是名副其實)
// 差的命名
int d; // 消逝的時間，以日計算。
// 好的命名
int elapsedTimeInDays;
int daysSinceCreation;
int daysSinceModification;
int fileAgeInDays;
- 選擇體現本意的名稱能讓人更容易理解和修改代碼。
public List<int[]> getThem() {
List<int[]> list1 = new ArrayList<int[]>();
for (int[] x : theList) {
if (x[0] == 4) {
list1.add(x);
}
}
return list1;
}
上面代碼雖然簡潔，但是我們能說清楚它到底做了啥嗎？ 問題不在于代碼的簡潔度，而是在于代碼的模糊度：即上下文在代碼中未被明確體現的程度。上面代碼要求我們了解類似一下問題的答案：
- theList中是什么類型的東西
- theList零下標條目的意義是什么
- 值4的意義是什么
- 我怎么使用返回的列表
問題的答案沒體現在代碼段中，而這本就是它們應該在的地方。比如，我們正在開發一款掃雷游戲，我們發現盤面是名為theList的單元格列表，那就將其名稱改為gameBoard。
盤面上每個單元格都用一個簡單數組表示。我們還發現，零下標條目是一種狀態的值，而這種狀態值為4表示為“已標記”。只要改為有意義的名稱，代碼就會得到相當程度的改進。
public List<int[]> getFlaggedCells() {
List<int[]> flaggedCells = new ArrayList<>();
for (int[] cell : gameBoard) {
if (cell[STAUS_VALUE] == FLAGGED) {
flaggedCells.add(cell);
}
}
return flaggedCells;
}
還可以更進一步，不用int數組表示單元格，而是另寫一個類。該類包括一個名副其實的函數（稱為isFlagged），從而掩蓋住那個魔術數（就是那個4）。于是得到函數的新版本：
public List<Cell> getFlaggedCells() {
List<Cell> flaggedCells = new ArrayList<>();
for (Cell cell : gameBoard) {
if (cell.isFlagged()) {
flaggedCells.add(cell);
}
}
return flaggedCells;
}
只要簡單改一下名字，就能輕易知道發生了什么。這就是選好名字的力量
2. 避免誤導
程序員必須避免留下掩蓋代碼本意的錯誤線索。應當避免使用與本意相悖的詞。例如，別用accountList來指稱一組賬號，除非它真的是List類型（即便容器就是一個List，最好也別在名稱中寫出容器類型名）。如果包含賬號的容器并非真是個List，就會引起錯誤的判斷。所以，用accountGroup或bunchOfAccounts，甚至直接用accounts都會好一些。
提防使用不同之處較小的名稱。相區分模塊中某處的XYZControllerForEfficientHandlongOfStrings和另一處的XYZControllerForEfficientStorageOfStrings，會花多長時間呢？ 這兩個詞外形實在是太像了。
誤導性名稱真正可怕的例子是使用小寫的字母l和大寫的字母O作為變量名，尤其是在組合使用的時候。問題在于，它倆看起來完全像是數字1和0。
3. 做有意義的區分
數字系列和廢話名稱，可以滿足編譯器，但是遠遠不夠。
public static void copyChars(char[] a1, char[] a2) {
for (int i = 0; i < a1.length; i++) {
a2[i] = a1[1];
}
}
以數字系列命名(a1, a2, ......aN)是依義命名的對立面。這樣的名稱純屬誤導——完全沒有提供正確的信息，沒有提供導向作者意圖的線索。
如果將參數名改為source和destination，這個函數將會像樣很多。
廢話是另一種沒有意義的區分。假設你有一個Product類。如果還有一個ProductInfo或ProductData類，那它們的名稱雖然不同，意思卻沒區別。Info和Data就像a、an和the一樣，是意義含混的廢話。
如果缺少明確約定，變量moneyAmout就與money沒區別，customerInfo與customer沒區別，accountData與account沒區別，theMessage也與message沒區別。要區分名稱，就要以讀者能鑒別不同之處的方式來區分。
4. 使用讀的出來的名稱
能讀出來的名稱更容易記憶。如果名稱讀不出來，討論的時候就像個傻鳥。
Date genymdhms // 生成日期，年、月、日、時、分、秒
Date generationTimestamp;
5. 使用可搜索的名稱
找MAX_CLASSES_PER_STUDENT比找數字7要容易得多。同樣字母e也不是個便于搜索的變量名。因為太常見了。
單字母名稱僅用于短方法中的局部變量。名稱長短應與其作用域大小相對應。如果變量或常量可能在代碼中多處使用，則應賦予其以便于搜索的名字。
6. 避免將類型或作用域編進名稱中
- 匈牙利語標記法（Hungarian Notation,HN）
早期編譯器不做類型檢查，程序員需要用匈牙利語標記法（Hungarian Notation,HN）來幫助自己記住類型。
在Windows的C語言API的時代，HN非常重要，傳說HN是為了紀念具有傳奇色彩的微軟程序員Charles Simonyi。這種標記法比較簡單：即變量名以表明該變量數據類型的小寫字母開始。
例如szCmdLine的前綴sz代表string end of zero.以0 結尾的字符串。
strPhone,代表Phone是字符串類型。
而今，大部分語言是強類型的，代碼編輯環境都已經先進到在編譯開始前就偵測到類型錯誤的程度！所以HN和其他類似的格式編碼都多余了。
它們增加了修改變量，函數，或類的名稱或類型的難度。
PhoneNumber phoneString;
//類型變化時，名稱并未變化。
- 成員前綴
也不必用 m_ 前綴來標明成員變量。應當把類和函數做得足夠小，消除對成員前綴的需要。
- 接口和實現
接口前導字母I被濫用。
7. 類名應該是名詞或名詞短語，方法名應該是動詞或者動詞短語
類名如Customer、WikiPage、Account。避免使用Manager、Processor、Data或Info這樣的類名
方法名如postPayment、deletePage或save。屬性訪問器、修改器或斷言應該根據其值命名，并依Javabean標準加上get、set和is前綴。
8. 同一概念對應統一個詞
比如get、fetch、retrieve表達的含義差不多，盡量保持多個類使用同一種寫法。
Controller、Manager、Driver含義相近，盡量保持一致。
9. 不用雙關語
10. 使用解決方案領域名稱
代碼是給程序員讀的，用計算機領域類的術語來命名是一個很好的做法。比如AccountVisitor、JobQueue這種。
如果不能用程序員熟悉的術語來命名，就采用所涉問題的領域名稱命名。
11. 添加有意義的語境、不要添加沒用的語境
如果你有命名良好的類、函數或命名空間來放置名稱，給讀者提供語境是最好不過了。如果沒有，就用最后一招———給名稱添加前綴。
比如，你有名為firstName、lastName、street、hourseNumber、city、state變量，擱一塊兒的時候，很明確是一個地址。如果只是在一個方法中單獨的看到一個state變量呢，你會理所當然得推斷是一個地址嗎？
可以添加前綴addrFirstName、addrLastName、addrState來提供語境。
假設有一個名為“加油站豪華版”(Gas Station Deluxe)的應用，在其中給每個類添加GSD前綴就不是什么好點子了。
