《代碼整潔之道》讀書筆記

代碼整潔之道

更有意義的命名

• 廢話是另外一種沒意義的區分。假設你有一個 Product 類。若是還有一個 ProductInfo 或ProductData類，那它們的名稱雖然不一樣，意思卻無區別。Info和Data就像a、an和the同樣，是意義含混的廢話
• 使用讀得出來的名稱：人類長於記憶和使用單詞。大腦的至關一部分就是用來容納和處理單詞的。單詞能讀得出來。人類進化到大腦中有那麼大的一塊地方用來處理言語，若不善加利用，實在是種恥辱
• 竊覺得單字母名稱僅用於短方法中的本地變量。名稱長短應與其做用域大小相對應
• ::類名和對象名：應該是名詞或名詞短語::，如Customer、WikiPage、Account和AddressParser。避免使用Manager、Processor、Data或Info這樣的類名。類名不該當是動詞
• ::方法名：應當是動詞或動詞短語::，如postPayment、deletePage或save。屬性訪問器、修改器和斷言應該根據其值命名，並依Javabean標準[10]加上get、set和is前綴
• 取好名字最難的地方在於須要良好的描述技巧和共有文化背景。與其說這是一種技術、商業或管理問題，還不如說是一種教學問題。其結果是，這個領域內的許多人都沒能學會作得很好

函數

• ::函數的第一規則是要短小。第二條規則是還要更短小::。我沒法證實這個斷言。我給不出任何證明了小函數更好的研究結果。我能說的是，近40年來，我寫過各類不一樣大小的函數。我寫過使人憎惡的長達3000行的厭物，也寫過許多100行到300行的函數，我還寫過20行到30行的。通過漫長的試錯，經驗告訴我，函數就該小
• ::函數應該作一件事。作好這件事。只作這一件事。::
• 要判斷函數是否不止作了一件事，還有一個方法，就是看是否能再拆出一個函數，該函數不只只是單純地從新詮釋其實現
• 參數： ::最理想的參數數量是零::（零參數函數），其次是一（單參數函數），再次是二（雙參數函數），應儘可能避免三（三參數函數）。有足夠特殊的理由才能用三個以上參數（多參數函數）。有兩個參數的函數要比一元函數難懂，對於一元函數，函數和參數應當造成一種很是良好的動詞/名詞對形式。例如，write(name)就至關使人認同。無論這個「name」是什麼，都要被「write」。更好的名稱大概是writeField(name)，它告訴咱們，「name」是一個「field」
• 標示參數：::標識參數醜陋不堪。向函數傳入布爾值簡直就是駭人聽聞的作法::。這樣作，方法簽名馬上變得複雜起來，大聲宣佈本函數不止作一件事。若是標識爲true將會這樣作，標識爲false則會那樣作！

在代碼清單3-7中，咱們別無選擇，由於調用者已經傳入了那個標識，而我想把重構範圍限制在該函數及該函數如下範圍以內。方法調用render(true)對於可憐的讀者來講仍然摸不着頭腦。捲動屏幕，看到render(Boolean isSuite)，稍許有點幫助，不過仍然不夠。應該把該函數一分爲二：reanderForSuite( )和renderForSingleTest( )

• 「Try/catch代碼塊醜陋不堪。它們搞亂了代碼結構，把錯誤處理與正常流程混爲一談。最好把try和catch代碼塊的主體部分抽離出來，另外造成函數。
• 「函數應該只作一件事。錯誤處理就是一件事。所以，處理錯誤的函數不應作其餘事。這意味着（如上例所示）若是關鍵字try在某個函數中存在，它就該是這個函數的第一個單詞，並且在catch/finally代碼塊後面也不應有其餘內容」
• 別重複本身：重複多是軟件中一切邪惡的根源。許多原則與實踐規則都是爲控制與消除重複而建立
• 寫代碼和寫別的東西很像。在寫論文或文章時，你先想什麼就寫什麼，而後再打磨它。初稿也許粗陋無序，你就斟酌推敲，直至達到你心目中的樣子。

我寫函數時，一開始都冗長而複雜。有太多縮進和嵌套循環。有過長的參數列表。名稱是隨意取的，也會有重複的代碼。不過我會配上一套單元測試，覆蓋每行醜陋的代碼。大師級程序員把系統看成故事來說，而不是看成程序來寫

註釋

• 註釋的恰當用法是彌補咱們在用代碼表達意圖時遭遇的失敗。注意，我用了「失敗」一詞。我是說真的。註釋老是一種失敗。咱們總沒法找到不用註釋就能表達自個人方法，因此總要有註釋，這並不值得慶賀
• 我爲何要極力貶低註釋？由於註釋會撒謊。也不是說老是如此或有意如此，但出現得實在太頻繁。註釋存在的時間越久，就離其所描述的代碼越遠，愈來愈變得全然錯誤。緣由很簡單。程序員不能堅持維護註釋
• 真實只在一處地方有：代碼。只有代碼能忠實地告訴你它作的事。那是惟一真正準確的信息來源。因此，儘管有時也須要註釋，咱們也該多花心思儘可能減小注釋量