我們都曾經(jīng)瞟一眼自己親手造成的混亂，決定棄之不顧，走向新的一天。我們都曾經(jīng)看到自己的爛程序居然能運行，然后斷言能運行的爛程序總比什么都沒有強，我們都曾經(jīng)說過有朝一日再回頭清理。當然，在那些日子里。我們都沒有聽過布朗法則：later equals never 稍后等于永不.
看到這句話確實有點慚愧。印象最深的感覺就是，我們?nèi)タ匆粌赡昵白约旱拇a，真的是自己都看不下去。要讓我改，我情愿再實現(xiàn)一個。所以時刻保持好的習慣是多么重要。不要想著以后再解決。就像領(lǐng)導(dǎo)說，這個事情以后再考慮，然后就沒有然后了
第一章 整潔代碼
怎樣是整潔的代碼？
代碼作品就像藝術(shù)品一樣，有不同的流派，在大師的眼里，對于優(yōu)美與漂亮有不同的理解。關(guān)于什么是整潔代碼書中講述很多大師的觀點，各個側(cè)重點不同。
Bjarne Stroustrup 說：
“我喜歡優(yōu)雅和高效的代碼，代碼邏輯應(yīng)當直接了當，叫缺陷難以隱藏；盡量減少依賴關(guān)系，使之便于維護；依據(jù)某種分層戰(zhàn)略完善錯誤處理代碼；性能調(diào)至最優(yōu)，省得引誘別人做沒有必要的優(yōu)化，搞出一堆混亂來，整潔的代碼只做好一件事?！?/p>
Ron Jeffries 對整潔代碼的理解：
1.能通過所有的測試。
2.沒有重復(fù)代碼。
3.體現(xiàn)系統(tǒng)中的全部設(shè)計理念。
4.包含盡量少的實體、比如類、方法、函數(shù)等。
5.盡量少的依賴關(guān)系，便于維護。
6.整潔的代碼淺顯易懂，絕不故作高深；
“在以上諸項中，我最在意的是代碼重復(fù)。如果一段代碼重復(fù)出現(xiàn)，就表示某種想法未在代碼中得到良好的提現(xiàn)。我會盡力去找出到底那是什么，然后在盡力的更清晰的表達出來?！?/p>
總結(jié)下就是整潔的代碼：1.職責明確，沒有多余。2.減少依賴，便于維護。3.高效。
第二章? 有意義的命名
1.名副其實。 說起來很簡單。選個好名字需要花時間，但省下的時間比花掉的多。注意命名，一旦有好的命名，就換掉舊的。
int d;//消失的時間，以日計。int elapsedTimeInDays，int daysSinceCreation;
我們定義不同的變量，能夠看到名字就知道是什么意思，這是最基本的要求了。
2.避免誤導(dǎo)。比如不是List類型，就不要用個accountList來命名，這樣形成誤導(dǎo)。
3.做有意的區(qū)分。
Public static void copyChars(char a1[],char a2[]){
for(int i=0;i<a1.length;i++){
a2[i]=a1[i]
}
}
如果參數(shù)名稱改為source和destination ，這個函數(shù)就會像樣很多。廢話都是冗余的，Variable一詞?永遠不應(yīng)當出現(xiàn)在變量名中。Table一詞永遠不應(yīng)當出現(xiàn)在表名中。NameString 會比 Name好嗎，難道Name 會是一個浮點數(shù)不成？如有一個Customer的類，有又一個CustomerObject的類。是不是就凌亂了。
4.使用便于搜索的的名稱
單個字母或者數(shù)字常量是很難在一大堆文章中找出來。比如字母e，它是英文中最常用的字母。長名勝于短名稱，搜得到的名稱勝于自編的名稱。 竊以為單字母的名稱僅用于短方法中的本地變量。名稱長短應(yīng)與其作用域大小相對應(yīng)。
5.類名應(yīng)該是名詞或短語
像Customer，Account，避免使用Manager,Processor,Data或者Info這樣的類名。類名不應(yīng)當是動詞。方法名應(yīng)該是動詞或動詞短語，如postPayment ,deletePage或Save，屬性訪問、修改和斷言應(yīng)該根據(jù)其值來命名，并加上get，set，is這些前綴。
6.別扮可愛,耍寶
比如誰知道HolyHandGrenada 函數(shù)是干什么的，沒錯這個名字挺伶俐，但是不過DeleteItems或許是更好的名字。
7.每個概念對應(yīng)一個詞。并且一以貫之。
在一堆代碼中有Controller，又有manager，driver。就會令人困惑。比如DeviceManager和Protal-Controller之間又什么本質(zhì)區(qū)別？
第三章 函數(shù)
1.函數(shù)的第一規(guī)則是要短小，第二條規(guī)則是還要更短小。
2.函數(shù)應(yīng)該做一件事。做好這件事。只做這一件事。
3.盡量少的函數(shù)參數(shù)。有兩個參數(shù)的函數(shù)要比一元函數(shù)的難懂。如果需要三個或者三個以上的參數(shù)應(yīng)該封裝成類了。
4.不要重復(fù)自己。
如果一段相同的代碼出現(xiàn)了兩次，你是不是覺得自己改做些什么了。
第四章 注釋
注釋的恰當用法是彌補我們在用代碼表達意圖時遭遇的失敗。事實上注釋是一種失敗，我們總無法找到不用注釋就能表達自我的方法，所以總要有注釋，這并不值得慶賀。寫注釋的常見動機之一是糟糕代碼的存在。帶有少量注釋的整潔而有表達力的代碼，要比帶有大量注釋的零碎而復(fù)雜的代碼像樣的多。與其花時間編寫解釋你搞出的糟糕的代碼注釋，不如花時間清潔那堆糟糕的代碼。
好注釋：
1. 法律信息。有時，公司代碼規(guī)范要求編寫與法律有關(guān)的注釋。例如版權(quán)和著作申明。
2.提供信息的注釋。
//Returns an instance of the Responder being?
protected abstract Responder responderInstance();
不過將函數(shù)名重新命名為 responderBeingTested 注釋就是多余的。
3.對意圖的解釋。?有時注釋不僅提供了有關(guān)實現(xiàn)的有用信息，而且還提供了某個決定后面的意圖。
4.闡釋。 有時注釋把某種晦澀難明的參數(shù)或返回值的意義翻譯為某種可讀形式。也會是有用的。特別是參數(shù)或者返回值是某個標準庫的一部分，或者你不能修改代碼，那幫助闡釋其含義的代碼就會有用，例如:
assertTrue(bb.compareTo(ba)==1); // bb>aa?
assertTrue(a.compareTo(b)== -1); // a<b
直接看方法可能不明確，但有注釋就明白多了。
5.警示，告訴別人要注意這個方法之類的。
6.放大。有的代碼可能看著有點多余，但編碼者當時是有他自己的考慮，這個時候需要注釋下這個代碼的重要性。避免后面被優(yōu)化掉。
