第三章 函式

1.函式的第一規則是要短小，第二條規則是還要更短小。 2.函式應該做一件事。做好這件事。只做這一件事。 3.儘量少的函式引數。有兩個引數的函式要比一元函式的難懂。如果需要三個或者三個以上的引數應該封裝成類了。 4.不要重複自己。 PS:如果一段相同的程式碼出現了兩次，你是不是覺得自己改做些什麼了。 第四章 註釋 註釋的恰當用法是彌補我們在用程式碼表達意圖時遭遇的失敗。作者認為註釋是一種失敗，我們總無法找到不用註釋就能表達自我的方法，所以總要有註釋，這並不值得慶賀。寫註釋的常見動機之一是糟糕程式碼的存在。帶有少量註釋的整潔而有表達力的程式碼，要比帶有大量註釋的零碎而複雜的程式碼像樣的多。與其花時間編寫解釋你搞出的糟糕的程式碼註釋，不如花時間清潔那堆糟糕的程式碼。 PS:這段話看起來可能有些過激。我們確實可以通過好的編碼習慣減少不必要的註釋。不過現在自動生成文件的技術都是從程式碼的註釋中提取的。如果是這種情況，上司肯定是要求你寫完備的註釋的。 好註釋： 1. 法律資訊。有時，公司程式碼規範要求編寫與法律有關的註釋。例如版權和著作申明。 2.提供資訊的註釋。

// returen an instance of the Responder being tested
protected abstract Responder responderInstance();

不過作者認為將函式名 重新命名為 responderBeingTested 註釋就是多餘的。

3.對意圖的解釋。有時註釋不僅提供了有關實現的有用資訊，而且還提供了某個決定後面的意圖。 4.闡釋。 有時註釋把某種晦澀難明的引數或返回值的意義翻譯為某種可讀形式。也會是有用的。特別是引數或者返回值是某個標準庫的一部分，或者你不能修改程式碼，那幫助闡釋其含義的程式碼就會有用，例如:

assertTrue(bb.compareTo(ba)==1);//bb>aa
assertTrue(a.compareTo(b)==-1);//a<b

直接看方法可能不明確，但有註釋就明白多了。我看這2,3,4都是一個意思。就是說明是幹嘛的。

5.警示，告訴別人要注意這個方法之類的。

6.放大。有的程式碼可能看著有點多餘，但編碼者當時是有他自己的考慮，這個時候需要註釋下這個程式碼的重要性。避免後面被優化掉。

連結：https://www.cnblogs.com/stoneniqiu/p/4815259.html?utm_medium=referral

以前自己的做法：以前自己沒有想到函式的簡化，總是想把一個功能作為一個函式，不管複雜不復雜，也有很多地方一直重複了，相同的部分有很多，因為對呼叫不太熟練，註釋一方面不是很重視

現在應該如何做：函式記得簡便，記得把相同的地方，構造一個函式，簡化程式碼量，對於複雜的程式碼應該加註釋 防止下次看的時候i忘記