目錄
第一章 整潔代碼
第二章 有意義的命名
在編程中，命名隨處可見。我們給變量、函數、參數、類和包命名。好的命名能夠代碼讀起來更加容易。
名副其實
一個變量的名字應該體現出這個變量要做什麼事，應該怎麼用。如果名稱需要註釋來補充，那就不算是名副其實。
int d; //消逝的時間，以日計
int daysSinceCreation
// 選擇體現本意的名稱能讓然更容易理解和修改代碼
避免誤導
避免留下掩藏本意的錯誤線索，避免使用與本意相悖的詞。例如hp、aix和sco都不該勇子啊變量名，因爲他們都是UNIX平臺的專有名稱。
儘量避免使用List結尾。別用accountList來指稱一組賬號，除非它真的是個List類型。
提防使用不用之處較小的名稱。例如區分：
String XYZControllerForEffientHandlingOfStrings
String XYZControllerForEffientStorageOfStrings
區分這兩個變量會話費很多時間。假如相似的名稱依字母順序放在一起，且差異很明顯，那就會相當的有助益。
做有意義的區分
命名變量時要做有意義的區分。例如：
getActiveAccount();
getActiveAccouts();
getActiveAccoutInfo();
函數名稱沒有有意義的區分，很難做出區分。accountData與account沒區別，theMessage與message沒區別。要區分名稱，就要以讀者能鑑別不用之處的方式來區分。
使用讀的出來的名稱
人類長於記憶和使用單詞。人類進化到大腦中有那麼大的一塊提防用來處理語言，要利用起來。例如：
bee cee arr three cee enn tee
使用可搜索的名稱
單字母名稱和數字常量有個問題，就是很難在一大篇文字中找出來。找MAX_CLASS_PER_STUDENAT很容易，但找數字7就麻煩了，它可能是某些文件名或其他常量定義的一部分，出現在因不同意圖而採用的各種表達式中。
不要以單字母名稱僅用於短方法中的本地變量，名稱長短應與其作用域大小想對應。若變量或常量可能在代碼中多處使用，則應賦其以便與搜錯的名稱。
避免使用編碼
不要使用類型編碼
在強類型語言中，代碼編輯環境已經先進到編譯開始錢就偵測到類型錯誤的程度。所以將類型寫到變量名中增加了修改變量、函數或類的名稱或類型的難度。
不要使用成員前綴
不要使用前綴來標明成員比那兩。應當把類和函數做得足夠小，消除對成員前綴的需要。讀的代碼越多，眼中也沒有前綴，最後，前綴邊做來不入法眼的廢料，變做來就代碼的標誌物。
避免映射思維
不應當讓讀者在鬧鐘把你的名稱翻譯爲他們樹枝的名稱。這種問題經常出現在選擇使用問題領域屬於還是解決問題領域術語時。
類名
類名和對象名應該是名次或名詞短語，如Customer、WikiPage、Account和AddressParser。避免使用Manager、Processor、Data、Info這樣的類名。
類名不應當是動詞。
方法名
方法名應當是動詞或動詞短語。如postPayment、deletePage。屬性訪問器、修改器和斷言應該根據其值命名。
重載構造器時，使用描述了參數的靜態工廠方法名，例如：
Complex fulcrumPoint = Complex.FromRealNumber(23.0);
小結
在我看來給類、變量、方法名起一個好的名字非常重要，在自己和其他人閱讀代碼時，又一個好的命名會幫助快速的理解代碼，並且減少產生誤導。上面使一些命名的一些技巧，在平時命名時可以運用起來。
在給變量命名時，一定要體現這個變量的它職責，它是用來存放數據呢，還是某個狀態；變量的名字一定要是某個單詞或單詞的組合，一定不要有歧義。
命名和對象命名時應該是名詞或名詞短語，並且要具體一些，不要使用Data、Manager這樣的命名，因爲這些單詞都不具體，別人看來之後不知道具體指什麼。
給方法命名時一定是動詞加名詞的組合，最好還能夠結合參數來命名，這個別人讀起來如同一句話。
第三章 函數
函數是編程世界中不可少的部分，從剛開始學編程寫的“Hello World”程序就開始使用函數了，但是我們是否有思考過什麼樣的函數纔是一個好的函數？
短小的函數體
一個函數應該有幾行代碼呢？這個問題並沒有唯一的答案。Clean Code中提到一行代碼應該只有兩行、三行或四行。我覺得一個函數應該在10行左右。通常這樣的函數都會一幕瞭然，並且每個函數只做一件事。在閱讀代碼時，函數會依次把你帶到下一個函數。這就是函數應該達到的短小的程度
代碼塊和縮進
在if語句、else語句、while語句的代碼應該將他們封裝爲一個函數，這樣在能夠保證函數短小，並且封裝好的函數在名字上也更容理解這段代碼的功能，增加了文檔上的價值。
小的函數體意味着不應該有着很多層的嵌套結構。所以，函數的縮進層級不該多於一層或者兩層。這樣的函數是易於閱讀和理解。
只做一件事
函數應該只做一件事，並且做好這件事。判斷一個函數是否不止做了一件事，又一個方法，就是看是否能夠再拆出一個函數，該函數不僅只是單純地重新詮釋其實現。
將代碼抽象成函數是爲了方便代碼閱讀，可以過濾掉不不要的信息。可能一個函數中有需要步驟，從準備數據到計算數據可能會有多個步驟，如果我們將這些小步驟的代碼封裝到一個函數中，然後使用一個高抽象層的函數來調用這些小步函數，則函數還是隻做來一件事。
每個函數一個抽象層級
要確保函數只做一件事，函數中的語句都要在同一抽象層級上。代碼寫的越具體，抽象層級卻低，如果一個函數中的代碼都是調用其他封裝好的函數，那麼這個函數抽象層級很高。
函數中混雜不同抽象層級，往往讓人迷惑。讀者可能無法判斷某個表達式是基礎概念還是細節。
自頂向下讀代碼：向下規則
讓代碼擁有自頂向下的閱讀順序。想要讓每個函數後面都跟着位於下一抽象層級的函數，這樣依賴，在查看函數列表時，就能按照抽象層級向下閱讀了。
我們想要這樣讀程序：程序就像是一系列TO起頭的段落，每一段都描述當前的抽象層級，並且位於一下抽象層級的後續TO起頭段落。
switch語句