讀書筆記--代碼整潔之道第三、四章

第三章 函數

1、函數的第一規則是要短小。第二條規則是還要更短小。

if 語句、else 語句、while 語句等,其中的代碼塊應該只有一行。該行大抵應該是一個函數調 用語句。

2、只做一件事

如果函數只是做了該函數名下同一抽象層上的步驟,則函數還是隻做了一件事。

要判斷函數是否不止做了一件事,還有一個方法,就是看是否能再拆出一個函數,該函數不僅只是單純地重新詮釋其實現。

要確保函數只做一件事,函數中的語句都要在同一抽象層級上。

3、自頂向下讀代碼:向下規則

程序就像是一系列TO起頭的段落,每一段都描述當前抽象層級,並引用位於下一抽象層級的後續 TO 起頭段落。

4、switch 語句

對於 switch語句,我的規矩是如果只出現一次,用於創建多態對象,而且隱藏在某個繼承關係中,在系統其他部分看不到,就還能容忍。

5、使用描述性的名稱

別害怕長名稱。長而具有描述性的名稱,要比短而令人費解的名稱好。

別害怕花時間取名字。

選擇描述性的名稱能理清你關於模塊的設計思路,並幫你改進之。

命名方式要保持一致。使用與模塊名一脈相承的短語、名詞和動詞給函數命名。

6、函數參數

最好是沒有參數,其次分別是一個參數、兩個參數,儘量避免使用三個參數,無論如何都不要用三個以上。

6、1單參數函數

對於有輸入參數和返回值的函數需寫清函數名,並且在上下文一直使用這個函數名。 對於有輸入參數而沒有返回值的函數(事件)應該讓讀者很清楚地瞭解它是個事件。謹慎地選用名稱和上下文語境。

對於以輸入參數作爲輸出參數的看,如果函數要對輸入參數進行轉換操作,轉換結果就該體現爲返回值。

6.2 標識參數

向函數傳入布爾值簡直就是駭人聽聞的做法。這樣做,方法簽名立刻變 得複雜起來,大聲宣佈本函數不止做一件事。----不應向函數傳入布爾值

6.3 兩個參數

除了向座標這樣兩個座標非常合理的函數外,應儘量將兩個參數的函數分爲一個參數的函數。

6.4 參數對象

當參數過多時可以將有關聯的參數適當的封裝成對象。

6.5 無副作用

它會對自己類中的變量做出未能預期的改動。有時,它會把變量搞成向函數傳遞的參數或是系統全局變量。無論哪種情況,都是具有破壞性的,會導致古怪的時序性耦合及順序依賴。

6.6 分隔指令與詢問

函數要麼做什麼事,要麼回答什麼事,但二者不可得兼。

6.7 使用異常替代返回錯誤碼

6.8 抽離 Try/Catch 代碼塊

函數應該只做一件事。錯誤處理就是一件事。如果關鍵字try在某個函數中存在,它就該是這個函數的第一個單詞,而且在 catch/finally代碼塊後面也不該有其他內容。

6.9 別重複自己

要儘量的消除重複

6.10 結構化編程

每個函數、函數中的每個代碼塊都應該有一個入口、一個出口。遵循這些規則,意味着在每個函數中只該有一個 return 語句,循環中不能有 break 或 continue 語句,而且永永遠遠不能有任何 goto 語句。

但對於小函數,這些規則助益不大。只有在大函數中,這些規則纔會有明顯的好處。

7、 如何寫好函數

不斷的打磨,重寫,直到達到上面的要求

第四章 註釋

1、註釋的恰當用法是彌補我們在用代碼表達意圖時遭遇的失敗

2、不準確的註釋要比沒註釋壞的多

3、有些註釋是必須的,也是有利的。但是真正好的註釋是想辦法不去寫的註釋。

好的註釋:

4、法律信息

5、提供信息的註釋

6、提供信息的註釋

比如 解釋某個抽象方法的返回值

有時管用,但是最好的方法還是改代碼

7、對意圖的解釋

8、闡釋

把某些晦澀難明的參數或返回值的意義翻譯爲某種可讀的形式。最好的方法就是直接講明,但是對於參數或返回值是一個標準庫的一部分,或者是你不能修改的代碼,註釋就會有用。

9、警示

警告程序員會出現某種後果。

10、TODO註釋

在源代碼中放置要做的工作列表。TODO解釋了爲什麼該函數的實現部分無所作爲,將來應該是怎樣。需要定期刪除

11、放大某種看起來不合理之物的重要性

12、公共API中的Javadoc

如果在編寫公共API,就需要爲他編寫Javadoc

壞註釋:

13、喃喃自語

14、多餘的註釋

15、循規式註釋

16、日誌式註釋

會讓模塊變的凌亂不堪,應當全部刪除

17、廢話註釋

18、位置標記

如:

//////Action/////////

標記理應全部刪除,如果濫用標記欄,將導致沉醉在背景雜音中,將個別註釋忽略掉

19、括號後面的註釋

可能對於含有長嵌套的函數存在意義,但是當你想寫長嵌套的時候,不如縮短函數。

20、歸屬與署名

源代碼控制器是這類信息最好的歸屬地。

21、註釋掉的代碼

源代碼管理器可以幫我們記住刪除的代碼,所以我們無需再用註釋來標記,刪掉即可。

22、HTML 註釋

23、非本地信息

如果非要給出註釋,請確保他描述了離它最近的代碼。

24、信息過多

25、不明顯的聯繫

註釋及其描述的代碼之間的聯繫應該是顯而易見的。

26、函數頭

27、非公共代碼的Javadoc





發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章