取名篇
1.類名和對象名應該是名詞或名詞短語。如customer,account。避免使用Manager,Processor這樣的類名。
2.方法名應當是動詞或動詞短語。如:postPayment,deletePage或save。屬性通路器,修改器和斷言應該根據具體指令,并依照javaBean的标準,加上get,set和is字首。
3.重載構造器時,使用靜态工廠好于直接使用構造器。例如:
User user =new User("張三")
User user =User.name("張三");
在其他書上也有提及這個,具體哪本書就忘了。
4.不要用諺語,梗來當方法名。方法名要做到言到義到。(方法名這個很重要,好的名字應該做到看方法名就知道這個方法具體做什麼)
5.一詞一意。比如add,可以表示String的字元串拼接,又可以表示新增某個事物到資料庫。那麼你就可以用insert來表示新增到資料庫。
函數篇
1.函數應該短小精幹!
2.基于短小精幹之後,函數應該隻做一件事情。做好這件事情。隻做這一點事情。
3.函數名稱的關鍵在于描述性,而不是長短。
4.函數的參數應該盡可能的少。
4.1比如一進制函數很好了解,因為隻有一個參數。
4.2二進制函數例如:appendStr(a,b),兩個參數同為一個類型,你能知道哪個是要追加的字元串,一個是被追加的字元串麼。所 以文中提及有條件的話可以把二進制函數轉為一進制函數,如上例子可以改為,a.appendStr(b)。
4.3三元函數就更加複雜了,相信大家也一定也有過放錯參數位置的經曆。
文中也提及如果有三個或三個以上的參數,就可以把參數封裝為類了。
5.函數名應該為動詞,标示做什麼的。
6.一個函數應該隻做一個事情。文中的例子我覺得很好。它講述的是 一個檢查賬号密碼的方法,函數名叫checkPassword,傳回boolean。我們在習慣的會在賬号密碼校驗成功後把使用者存入session,是以例子也不例外。但是這就違反了單一職責原則,也就是函數應該隻做一件事,最好一件事。這樣造成的後果是,如果我們信了這個方法名僅僅是檢查賬号密碼,那麼他可能會抹去現在正進行的session。
7.抽離try,catch代碼塊。可以把try/catch裡面的代碼抽離成一個方法。這樣便于修改和友善閱讀。
7.1 插一個小話題,關于為什麼要用異常類。傳回錯誤碼的話,一般會有個專門定義所有異常code的常量類或者枚舉類。這樣的話如果要新增異常就會重新編譯部署所有引入這個常量類或者枚舉類。造成了負面壓力。如果用異常類,就無需編譯或重新部署、這也是文中提及到的地方。
小結:寫函數時,一開始都冗長而複雜。有太多的縮進和嵌套循環。有過長的參數清單。名字是随便取得,也會有重複的代碼。不過我會配上一套單元測試,覆寫每行醜陋的代碼。然後我打磨這些代碼,分解函數,修改名稱,消除重複。我縮短和重新安放方法。有時我還拆散類。同時保持單元測試。我并不從一開始就按照規則寫函數。我想沒人能做到。
注釋篇
作者并不認同代碼中用巨量的注釋來表達代碼的含義。作者更希望用讓代碼具有表達力來闡述其行為。
1.公共API應該具有較長的描述的注釋,但JAVADoc也有可能誤導,不适用或者提供錯誤資訊。
資料結構篇
這篇主要就介紹了為什麼要用DO(資料庫表結構類),以及不應該在這類對象裡面加上業務方法。
錯誤處理篇
本篇将帶領大家編寫出整潔又強固的錯誤處理代碼以及一些技巧和思路。
1.使用異常而非傳回碼
2.考慮使用特例對象(特例模式)
3.函數不要傳回null值
4.不要傳遞null值
邊界
如何将外來代碼幹淨利落的放入自己的代碼中。
1.運用好外來代碼的測試。
2.文中提出了可以用擴充卡模式來接入外來的代碼。
整潔的測試
文章中隻是粗略的提及了整潔測試的方法,具體我覺得還可以再去找本驅動測試的書看看。文中提倡驅動測試的方法,這樣做的好處有。
1.測試擁有全部的覆寫率,保證每個生産代碼的正确。
2.可以大膽的重構代碼,因為有測試的覆寫,不用畏畏縮縮的。
壞處:測試代碼同生産代碼一樣多,維護要維護兩份代碼。