代碼整潔之道

第二章:做有意義的命名 —(2017-08-03日)

• 1.名副其實:選個好的命名,見名知意,變量,或函數(shù),或類馮名稱應(yīng)該在看到名稱就已經(jīng)有了答案,如果名稱需要注釋來補充,那就不算是名副其實.
• 2.避免誤導:避免留下和代碼本意不符合的單詞
• 3.做有意義的區(qū)分:有時候代碼名稱雖然不同,但是名稱高含義確實相同的,這就導致程序員在看到命名時無法進行區(qū)別.
• 4.使用命名時,盡量使用我們能讀出來的單詞,避免與人交談時產(chǎn)生單詞讀不出來的尷尬,書中說,編程本來就是一種社會活動
• 5.使用可搜索的名稱:平常的單詞名稱和數(shù)字很難在代碼中找出來,因為肯定會不引用.長命勝于短名稱,但是如果短名稱足夠清楚,就要愛比長命稱好,若變量或常亮可能在代碼多處使用,應(yīng)該給其的命名,便于搜索.
• 6.避免使用編碼,避免使用前綴,在避必須使用編碼的特殊情況時,在接口和實現(xiàn)命名時,盡量選擇對實現(xiàn)進行編碼命名.
• 7類名:類名和對象名應(yīng)該是名詞或者名詞短語,類名不應(yīng)該是動詞.
• 8.方法名:方法名應(yīng)該是動詞或動詞短語.
• 9:命名時做到言到意到,意到言到.
• 10.每個概念對應(yīng)一個詞,我們在寫代碼時,應(yīng)當給每個抽象概念對應(yīng)一個詞,并且一以貫之.
• 11.盡量使用程序員熟悉的術(shù)語來命名,如果實在不能用術(shù)語命名,就采用所涉及領(lǐng)域名稱來命名.

第三章:函數(shù)

3.1-3.7節(jié)(2017-08-04日)

• 1.函數(shù)就應(yīng)該寫的短小,函數(shù)應(yīng)該二十行封頂.這樣最佳.if 或者else或者while語句,其中的代碼塊應(yīng)該只有一行,該行應(yīng)該是一個函數(shù)調(diào)用.這樣不但可以保持函數(shù)短小,還可以使用具有說明性的文字,使得代碼更易于閱讀和理解
• 2.只做一件事,函數(shù)應(yīng)該做一件事,做好這件事,只做這一件事.判斷函數(shù)是否不止做了一件事,就是看這個函數(shù)還能否拆分出一個函數(shù).因為只做一件事的函數(shù)無法唄被合理的切分為多個區(qū)域.
• 3.函數(shù)中的語句都要在同一抽象層級上,自頂向下讀代碼,讓每一個函數(shù)后面都跟著位于下一抽象層級 的函數(shù).
• 4.用描述性的名稱,當我們命名函數(shù)時,要讓函數(shù)名較好的描述函數(shù)做的事.函數(shù)越短,功能越集中,就越便于取個好名字.不要害怕名字長,因為具有描述性的長名字要比令人費解的短名稱好,也要比描述性的長注釋好,選擇描述性的名稱能清理自己關(guān)于模塊的設(shè)計思路,并幫改進之.而且命名方式應(yīng)該保持一致.
• 5.函數(shù)的參數(shù):最理想的函數(shù)時是沒有參數(shù)的,其次時是一個參數(shù),然后是兩個參數(shù),避免使用三個或者三個以上的參數(shù),切記,不到萬不得已的時候不要這樣做.

3.8-3.15節(jié)(2017-08-05日)

• 6.給函數(shù)取個好名字,能較好的解釋函數(shù)的意圖,以及參數(shù)的順序和意圖,對于一元函數(shù)和參數(shù),應(yīng)當形成一種良好的動詞/名詞對應(yīng)行式.
• 7.應(yīng)避免使用輸出參數(shù),如果函數(shù)必須要修改某種狀態(tài),就修改所屬對象的狀態(tài).
• 8.函數(shù)要么是在做一件什么事,要么是回答什么事,一般二者不可兼得,函數(shù)應(yīng)該修改某對象的狀態(tài),或者是返回該對象的有關(guān)信息,兩者不要都干,否則會導致混亂.
• 9.抽離try/catch代碼塊,將主體抽離出來形成函數(shù).處理錯誤就是一件事,處理錯誤的函數(shù)也只能做一件事.
• 10.重復代碼是軟件中一切邪惡的根源,重復代碼會增加代碼的臃腫,而且會增多代碼的錯誤率,許多原則與實踐規(guī)則都是為控制與消除重復而創(chuàng)建.
• 11.沒有人能從一開始就能寫出規(guī)整的代碼,所以在寫代碼時,先寫出來,再根據(jù)書中的方法,打磨,分解函數(shù),修改名稱,消除重復

第四章:注釋(2017-08-06日)

• 1.如果編程語言足夠有表達能力,或許我們擅長于用這門需要來表達意圖,那么就不需要注釋了.
• 2.為什么不建議使用注釋,因為代碼總是在改變,在演化,但是注釋卻不能總是隨之變動.
• 3.注釋不能美化糟糕的代碼,當你需要用注釋來解釋你糟糕的代碼時,倒不如花點時間清潔清潔自己糟糕的代碼.
• 4.很多時候,其實當我們來寫代碼時,只需要想上那么幾秒鐘,就能用代碼解釋自己的大部分意圖,只需要描述一個與注釋所言同一事物的函數(shù)即可.
• 5.什么是好的注釋,法律信息的注釋,例如有時候公司規(guī)范要求,編寫與法律有關(guān)的注釋.提供信息的注釋.公共api中的javadoc
• 6.能用函數(shù)或變量時就別用注釋.而且在括號后面編寫注釋時,會給我們編寫短小代碼和封裝代碼帶來混亂.
• 7.歸屬和署名,因為源代碼控制系統(tǒng)非常善于記住是誰在在何時添加了什么,所以沒有必要用小小的標簽名.
• 8.不要直接把代碼注釋掉,要么用,要么刪掉,這樣的代碼別人看到會以為是重要的,不會刪掉,這樣越來越多注釋代碼積累會弄臟我們的代碼.

第五章:格式(2017-08-08日)

• 1.我們應(yīng)該選用一套管理代碼格式的簡單規(guī)則,貫徹這套規(guī)則,在團隊中應(yīng)該一致同意,采用一套簡單的格式規(guī)則,所有成員都去遵從.
• 2.格式目的:代碼格式很重要,代碼格式不可忽略,必須嚴肅對待,代碼格式關(guān)乎團隊溝通,而溝通是專業(yè)開發(fā)者的頭等大事.
• 3.寫出來的代碼要像報紙上的文章一樣,名稱應(yīng)當簡單且一目了然.名稱本身應(yīng)該足夠告訴我們是否在正確的模塊中.
• 4.在封包聲明,導入聲明,和每個函數(shù)之間,都有空白行隔開,這條極簡單的規(guī)則,極大的影響了代碼的視覺外觀.每個空白行都是一條線索,標識出新的獨立的概念.
• 5.而緊密相關(guān)的代碼應(yīng)該互相靠近,不應(yīng)該被注釋隔斷代碼間的聯(lián)系.
• 6.關(guān)系密切的代碼就應(yīng)該相互靠近,但我們經(jīng)常遇到存在于不同文件的概念,不到萬不得已,應(yīng)該盡可能的把有密切相關(guān)的函數(shù)放在相同的文件.
• 7.變量的聲明.應(yīng)該盡可能的靠近其使用的位置.實體變量,應(yīng)該在類的頂部聲明至少在java代碼中應(yīng)該這樣.
• 8.相關(guān)函數(shù),如果某個函數(shù)調(diào)用了別的函數(shù),就應(yīng)該將其放在一起,并且調(diào)用者在被調(diào)用者上面.這樣就極大增加了模塊的可讀性.
• 9.空格字符,我們在賦值操作符周圍加上空格字符,以此達到強調(diào)的目的.
• 10.團隊規(guī)則,每個人都有自己的代碼格式規(guī)則,但是在團隊中,應(yīng)當認同同一種風格,并且每個人都去采用這種風格.

第六章:對象和數(shù)據(jù)結(jié)構(gòu)(2017-08-09日)

• 1.隱藏實現(xiàn)并非只是在變量之間放上一個函數(shù)層那么簡單,隱藏實現(xiàn)關(guān)乎抽象,類并不是簡單的取值器和賦值器,而是曝露抽象接口,以便用戶無需了解數(shù)據(jù)的實現(xiàn),就能操作數(shù)據(jù)本體.
• 2.對象把數(shù)據(jù)隱藏于抽象之后,曝露操作數(shù)據(jù)的函數(shù).數(shù)據(jù)結(jié)構(gòu)曝露其數(shù)據(jù),沒有提供有意義的函數(shù).
• 3.過程式代碼既使用數(shù)據(jù)結(jié)構(gòu)的代碼,難以添加新的數(shù)據(jù)結(jié)構(gòu),因為要修改所有的函數(shù),而面向?qū)ο蟮拇a難以添加新的函數(shù),因為必須修改所有類.
• 4.得墨忒耳律:模塊不應(yīng)該了解它所操作對象的內(nèi)部情形.
• 5.方法不應(yīng)該調(diào)用由任何函數(shù)返回的對象的方法.這類方式的代碼應(yīng)該杜絕.
• 6.最精煉的數(shù)據(jù)結(jié)構(gòu),是一個只有公共變量,沒有函數(shù)的類.這種數(shù)據(jù)結(jié)構(gòu)有時被稱為數(shù)據(jù)傳遞對象[DTD].
• 7.對象曝露行為,隱藏數(shù)據(jù),便于添加新對象類型,而無需修改既有行為,同時也難以在既有對象中添加新行為.
• 8.數(shù)據(jù)結(jié)構(gòu)曝露數(shù)據(jù),沒有明顯的行為,便于向既有的數(shù)據(jù)結(jié)構(gòu)添加新的行為,同時也難以向既有函數(shù)添加新數(shù)據(jù)結(jié)構(gòu).

第七章:錯誤處理(2017-08-11日)

• 1.遇到錯誤時,應(yīng)該拋出一個異常,這樣的調(diào)用代碼會很整潔,其邏輯不會被錯誤代碼弄亂.
• 2.先寫try-catch-Finally語句,當我們執(zhí)行try中的代碼時,表明可以隨時取消執(zhí)行,并且在catch中繼續(xù).
• 3.給出異常發(fā)生的環(huán)境說明,每次拋出異常,都行該提供足夠的環(huán)境說明,以便判斷錯誤的來源和出處.
• 4.當我們在應(yīng)用程序中定義異常類時,最重要的是考慮它們?nèi)绾伪徊东@.
• 5.別返回null,因為當你返回null時基本上就是給自己添加工作量,給調(diào)用者添亂.如果你打算在方法中返回null,不如拋出異常,或者是返回特例對象.
• 6.不要傳null值,除非是API要求null否則就不要給函數(shù)中傳入null值.
• 7.我們在代碼中應(yīng)該將錯誤處理隔離看待,獨立于主要的邏輯代碼,這樣就能寫出強固而整潔的代碼.也極大的提升了代碼可維護性.

第八章:邊界(2017-08-12日)

• 1.一般來說,第三方程序包和框架提供者追求普適性,而我們這樣的使用者則要滿足特定需求的接口即可,這>- 種張力會導致系統(tǒng)邊界上出現(xiàn)問題.
• 2.學習性測試毫無成本,無論如何我們都要學習要使用的api而編寫測試則是獲取這些知識的容易而不會影響其他工作途徑.
• 3.代碼中的邊界是將已知和未知分隔開的邊界.在代碼中總有許多地方是我們的知識未及之處.

第九章:單元測試(2017-08-14日)

• 1.TDD三定律：
  a.在編寫不能通過的單元測試前，不可編寫生產(chǎn)代碼。
  b.只可編寫剛好無法通過的單元測試，不能編譯也不算通過。
  c.可編寫剛好足以通過通過測試當前失敗測試生產(chǎn)代碼。
• 2.保持測試代碼整潔,測試代碼和生產(chǎn)代碼一樣重要。它需要被思考，被設(shè)計和被照料，它該像生產(chǎn)代碼一樣整潔。
• 3.如果測試不能保持整潔，你將會失去它們。沒有了測試，你就會失去保證生產(chǎn)代碼可擴展的一切要素。
• 4.測試代碼應(yīng)該要有可讀性。應(yīng)該和其他代碼一樣，明確，簡潔，還有足夠的表達力。
• 5.按照 構(gòu)造-操作-檢驗 模式，可以清晰的將測試拆分為三個環(huán)節(jié)。第一個環(huán)節(jié)構(gòu)造測試數(shù)據(jù)，第二環(huán)節(jié)操作數(shù)據(jù)，第三部分檢驗操作是否得到期望的結(jié)果。
• 6.整潔的代碼還要遵循以下規(guī)則。快速，獨立，可重復，足以驗證，及時。

第十章：類（2017-08-16日）

• 1.類的組織：類中應(yīng)該由一組變量列表開始，公共靜態(tài)常量在前，私有靜態(tài)變量在后，然后時私有實體變量，接著是公共變量。公共函數(shù)跟在變量列表之后。工具函數(shù)在公共函數(shù)之后。
• 2.類應(yīng)該短小，但是類的大小不取決于代碼行數(shù)，而取決于權(quán)責。
• 3.單一權(quán)責原則認為，類或模塊應(yīng)該由且只有一條加以修飾的理由。
• 4.系統(tǒng)應(yīng)該由許多短小的類而不是少量巨大的類組成。每個小類封裝一個權(quán)責，只有一個修改的原因。并與少數(shù)其他類一起協(xié)同達到期望的系統(tǒng)行為。
• 5.保持函數(shù)和參數(shù)列表短小的策略，有時會導致為一組子集方法所用的實體變量數(shù)量增加。出現(xiàn)這種情況應(yīng)該嘗試將這些變量和方法拆分到兩個或多個類中，讓新的類更內(nèi)聚。
• 6.保持內(nèi)聚性就會得到許多短小的類。

第十一章：系統(tǒng)

待讀。。