檢查表及總結 - 《代碼大全》

設計

• 設計是否通過屢次迭代，並最終決定了最好的一個？
• 是否同時使用自上而下和自下而上的方法來解決設計問題？
• 類與類之間的交互關係是否已經設計爲最小化？
• 設計被劃分爲層次嗎？
• 你對把這一程序分解成爲子程序，包和類的方式感到滿意嗎？
• 程序是否是易於維護？
• 設計是否精簡？設計出來的每個部分都絕對必要嗎？
• 總體而言，你的設計是否有助於最小化偶然性和本質性的複雜度嗎？

類的設計

• 你是否把程序中的類都看作是抽象數據類型了？是否從這個角度評估它們的接口了？
• 類是否有一箇中心目的？
• 類的命名是否恰當？其名字是否表達了其中新目的？
• 類的接口是否展示了一致的抽象？
• 類的接口是否能讓人清楚明白的知道如何用它？
• 類的接口是否抽象，使你能沒必要顧慮他是如何實現其服務的？你能把類看作黑盒子嗎？
• 類提供的服務是否足夠完整，讓其它類無需動用其內部數據？
• 是否已從類中去除無關信息？
• 是否考慮過把類進一步分解？
• 在修改類時是否維持了其接口的完整性？
• 是否把成員的可訪問性降到最小？
• 是否避免暴露類的數據成員？
• 類是否避免對其使用者，包括其派生類會如何使用它作了假設？
• 類是否不依賴於其它類？它是鬆散耦合嗎？
• 繼承是否只用來創建一個is a關係？派生類是否遵循了LSP原則。
• 繼承層次是否很淺？
• 類中是否只有大約七個或者更少的成員？
• 是否把類直接或者間接調用其餘類的子程序的數量減到最少？
• 類是否在絕對必要時才與其餘類寫做？
• 是否在構造函數中初始化了全部的數據成員？

子程序

• 建立子程序的理由充分嗎？
• 一個子程序中全部適合單獨提出的部分是否是已經被提出到單獨的子程序中了？
• 過程的名字是否用了強烈、清晰的動詞加賓語的詞組，函數的名字是否描述了其返回值？
• 子程序的名字是否描述它所做的所有事情？
• 子程序是否具備強烈的功能上的內聚性？
• 子程序之間是否有較鬆散的耦合？子程序與其它子程序之間的鏈接是不是最小的，明確的，可見的，靈活的？
• 子程序的長度是不是由其功能和邏輯天然肯定，而非遵循任何人爲的編碼標準？
• 子程序的參數表是否表現出一種具備總體性且一致的抽象？
• 子程序參數的排列順序是否合理？是否與相似的子程序的參數排列相符？
• 接口假定是否在文檔中說明？
• 子程序的參數是否沒有超過7個？
• 是否用到了每個輸入參數，是否用到了每個輸出參數？
• 子程序是否避免了把輸入參數用做工做變量？
• 若是子程序是一個函數，那麼它是否在全部可能的狀況下都能返回一個合法的值？

防護式編程

• 子程序是否保護本身免遭有害輸入數據的破壞？
• 你用斷言來講明編程假定嗎？其中包括了前條件和後條件了嗎？
• 斷言是否只說明歷來不該該發生的狀況？
• 你是否在架構或者高層設計中規定了一組特定的錯誤處理技術？
• 你是否在架構或者高層設計中規定了是讓錯誤處理更傾向於健壯性仍是正確性？
• 代碼中用到輔助調試的代碼了嗎？
• 在防護式編程時引入的代碼量是否適宜，既不過多也不過少？
• 你在項目中定義了一套標準化的異常處理方案嗎？
• 若是可能的話，是否在局部處理了錯誤而不是把它當成一個異常跑出去？
• 全部異常是否都與拋出他們的子程序在同一抽象層次上？
• 每一個異常是否包含了關於異常發生的全部背景信息？
• 代碼中是否沒有空的catch語句？
• 檢查有害輸入數據的代碼是否也檢查了故意的緩衝區溢出，SQL注入，HTML注入，整數溢出及其餘惡意輸入數據？
• 是否檢查了全部的錯誤返回碼？
• 是否捕獲了全部的異常？
• 出錯消息中是否避免出現有助於攻擊者攻入系統所需的信息？

僞代碼

• 是否檢查過已知足全部的先決條件？
• 定義好這個類要解決的問題了嗎？
• 高層次的設計是否清晰？能給這個類和其中的每一個子程序起一個好的名字嗎？
• 考慮過該如何測試這個類及其中的每一個子程序嗎？
• 關於效率的問題，你主要從穩定的接口和可讀的實現這兩個角度考慮嗎？仍是主要從知足資源和速度的預期目標的角度考慮過呢？
• 從標準庫函數和其它代碼庫中尋找過可用的子程序或者組件嗎？
• 從參考書中查過有用的算法了嗎？
• 是否用詳盡的僞代碼設計好每個子程序？
• 你在腦海裏檢查過僞代碼嗎？這些僞代碼容易理解嗎？
• 關注過那些可能讓你重返設計的警告信息了嗎？
• 是否把僞代碼正確的翻譯成代碼了？
• 你反覆使用僞代碼編程過程了嗎？
• 在作出假定的時候有沒有對它們加以說明？
• 已經刪除了那些冗餘的註釋了嗎？
• 你是否採起了幾回迭代中最好的那個結果？仍是在第一次迭代以後就中止了？
• 你徹底理解你的代碼了嗎？這些代碼是否容易理解？

變量

• 變量聲明位置靠近變量第一次使用的位置嗎？
• 儘量在變量聲明的同時初始化變量嗎？
• 計數器和累加器通過適當初始化了嗎？若是須要再一次使用，以前從新初始化了嗎？
• 適當的從新初始化「須要重複執行的代碼裏的變量」了嗎？
• 代碼在經過編譯器編譯的時候是否是沒有警告信息？你啓用了全部可用的警告信息了嗎？
• 若是語言容許隱式聲明，你爲由此可能引起的問題作好補償措施了嗎？
• 若是可能，全部變量都被定義爲具備最小的做用域嗎？
• 各變量的引用點都儘量集中在一塊兒嗎？對同一個變量的兩次相鄰引用，或者變量的整個生命期都這樣作了嗎？
• 控制結構符合數據類型嗎？
• 全部聲明的變量都用了嗎？
• 變量都在合適的時間綁定了嗎？也就是說你有意識的在晚期綁定所帶來的靈活性和增長複雜度之間作出平衡了嗎？
• 每一個變量都有且僅有一項用途嗎？
• 每一個變量的含義都很明確且沒有隱含含義嗎？

變量命名

• 名字完整而且準確的表達了變量所表明的含義嗎？
• 名字足夠長，可讓你無需苦苦思索嗎？
• 若是有計算限定符，它被放在名字後面嗎？
• 名字中用Count或者index來掉提Num了嗎？
• 循環小標的名字有意義嗎？
• 全部臨時的變量都從新命名爲更有意義的名字了嗎？
• 當布爾變量爲真時，變量能準確表達其含義嗎？
• 枚舉中的名字含有可以表示其類別的前綴或者後綴嗎？
• 具名常量是根據它所表明的抽象實體兒不是它所表明的數字來命名的嗎？
• 命名規則可以區分局部數據，類的數據和全局數據嗎？
• 規則可以區分類型名，具名常量，枚舉類型和變量名嗎？
• 規則可以在編譯器不強制檢測只讀參數的語言裏表示出子程序的輸入參數嗎？
• 規則能儘量地與語言的標準規則兼容嗎？
• 名字爲可讀性而加以格式化了嗎？
• 是否避免只爲了省一個字符而縮寫的狀況？
• 全部單詞的縮寫方式都一致嗎？
• 名字可以讀出來嗎？
• 避免使用容易被看錯和讀錯的名字嗎？
• 在縮寫對照表裏對端名字作出說明了嗎？

基本數據類型

• 代碼中避免使用神祕數值了嗎？
• 代碼考慮了除零錯誤了嗎？
• 類型轉換很明顯嗎？
• 若是一條語句中存在兩個不一樣類型的變量，那麼這條語句會像你指望的那樣求值嗎？
• 代碼避免了混合類型比較嗎？
• 使用整數除法表達式能按預期的那樣工做嗎？
• 整數表達式避免整數溢出問題了嗎？
• 代碼避免了對數量級相差具體大浮點數作加減運算了嗎？
• 代碼系統地阻止了舍入錯誤的發生嗎？
• 代碼避免對浮點數值作等量比較了嗎？
• 代碼避免使用神祕字符和字符串了嗎？
• 使用字符串時避免了off-bye-one錯誤了嗎？
• 程序用額外的布爾變量來講明條件判斷了嗎？
• 程序用額外的布爾變量來簡化條件判斷了嗎？
• 程序用枚舉類型而非具名常量來提升可讀性和可修改行了嗎？
• 當變量不能用true和false表示的時候，程序用枚舉類型來取代布爾變量了嗎？
• 針對枚舉類型的才測試檢測了非法數值了嗎？
• 把枚舉類型的第一項條目保留爲「非法的」了嗎？
• 具名常量使用一致嗎？沒有在某些位置使用具名常量又在其餘位置使用文字量？
• 全部的數組下標都沒有超出數組邊界嗎？
• 數組引用沒有出現off-by-one的錯誤嗎？
• 全部的多維數組的下標順序都正確嗎？
• 在嵌套循環裏，把正確的變量用於數組下標來避免下標錯亂嗎？

不常見的數據類型

• 你使用結構體而不是使用單純的變量來組織和操做相關的數據嗎？
• 你考慮過建立一個類來代替使用結構體嗎？
• 全部的變量是否都是局部或者是類範圍的？除非絕對有必要纔是全局的？
• 你對全部的全局變量都加以文檔說明嗎？
• 避免使用僞全局數據，即被四處傳遞且含有雜亂數據的的巨大對象嗎？
• 用訪問器子程序來取代全局數據了嗎？
• 把訪問其子程序和數據組織到類裏了嗎？
• 訪問器子程序提供了一個在底層數據類型實現之上的抽象層嗎？
• 全部相關的訪問器子程序都位於同一抽象層嗎？
• 把指針操做隔離在子程序裏了嗎？
• 指針引用合法嗎？或者指針有可能成爲懸空指針嗎？
• 代碼在使用指針以前檢查它的有效性了嗎？
• 在使用指針所指向的變量以前檢查其有效性了嗎？
• 指針用完後被設置爲空了嗎？
• 就可讀性而言，代碼用了全部須要使用的指針變量了嗎？
• 鏈表中的指針是按正確的順序加以釋放的嗎？
• 程序分配了一片保留的內存後備區域，以便在耗盡內存的時候可以優雅地退出嗎？
• 是否是在沒有其餘方法可用的狀況下最終才使用指針的？

組織直線型代碼

• 代碼使得語句之間的依賴關係變得明顯嗎？
• 子程序的名字使得依賴關係變得明顯嗎？
• 子程序的參數使得依賴關係變得明顯嗎？
• 若是依賴關係不明確，你是否用註釋進行了說明？
• 你用「內務管理變量」來檢查代碼中關鍵位置的順序依賴關係了嗎？
• 代碼容易按照自上而下的順序閱讀嗎？
• 相關的語句組織在一塊兒嗎？
• 把相對獨立的語句組放進各自的子程序裏嗎？

使用條件語句

• 代碼的正常路徑清晰嗎？
• if-then測試對等量分支的處理方式正確嗎？
• 使用了else字句並加以說明了嗎？
• else字句用的對嗎？
• 用對了if和else字句，即沒有把它們用反嗎？
• 須要執行的正常狀況維護if而不是else字句裏嗎？
• if-then-else-if把複雜的判斷封裝到布爾函數裏了嗎？
• if-then-else-if先判斷最多見的狀況了嗎？
• if-then-else-if判斷包含全部的狀況嗎？
• if-then-else-if是最佳的實現嗎？比Case語句還要好嗎？
• case子句排序的有意義嗎？
• case子句的每種狀況操做簡單嗎？必要的時候調用了其它子程序了嗎？
• case語句檢測的是一個真實的變量，而不是爲了濫用case語句而而刻意製造變量嗎？
• 默認字句用的合法嗎？
• 用默認字句來檢測和報告意料以外的狀況了嗎？
• 在c,c++和java裏，每個case的末尾有一個break嗎？

循環

• 在合適的狀況下用while循環取代for循環了嗎？
• 循環是由內到外建立的嗎？
• 是從循環的頭部進入循環的嗎？
• 初始化代碼是直接位於循環前面嗎？
• 循環是無限循環或者事件循環嗎？阿德結構是否清晰？
• 避免使用像for i = 1 to 9999這樣的代碼嗎？
• 若是這是一個c++,c或java中的for循環，那麼把循環頭留給循環控制代碼了嗎？
• 循環使用了{}及其等價物來括上循環體，以防止因修改不當而出錯嗎？
• 循環體內有內容嗎？他是非空的嗎？
• 把內務處理集中地放在循環開始或者循環結束處了嗎？
• 循環像定義良好的子程序那樣只執行一件操做嗎？
• 循環短的足以一目瞭然嗎？
• 循環的嵌套層次很少於3層嗎？
• 把長循環的內容提取成單獨的子程序嗎？
• 若是循環很長，那麼它很是清晰嗎？
• 若是這是一個for循環，那麼其中的代碼有沒有隨意修改循環下標值？
• 是否把重要的循環下標值保存在另外的變量裏，而不是在循環體外使用該循環下標？
• 循環下標是序數類型或者枚舉類型，而不是浮點類型嗎?
• 循環下標的名字有意義嗎？
• 循環避免了下標串話問題嗎？
• 循環是在全部可能的條件下都能終止嗎？
• 若是創建了某種安全計數器標準，循環使用了安全計數器了嗎？
• 循環的退出條件清晰嗎？
• 若是使用了break或者continue，那麼它們用對了嗎？
• 不常見的控制結構
• 每個子程序都僅在有必要的時候才使用return嗎？
• 使用return有助於加強可讀性嗎？
• 遞歸子程序中包含了中止遞歸的代碼嗎？
• 子程序用安全計數器來確保子程序能停下來嗎？
• 遞歸只位於一個子程序裏面嗎？
• 子程序遞歸深度處於程序棧容量能夠知足的限度內嗎？
• 遞歸是實現子程序的最佳方法嗎？它要好於簡單的迭代嗎？
• 是否在萬不得已的時候才使用goto？若是用了goto，是否僅僅處於加強可讀性和可維護性呢？
• 若是處於效率因素而使用的goto，那麼對這種效率上的提高作出衡量而且加以說明了嗎？
• 一個子程序裏最多隻用了一個goto標號嗎？
• 全部的goto都向前跳轉，而不是向後跳轉嗎？
• 全部的goto標號都用到了嗎？

表驅動法

• 你考慮過把表驅動法做爲複雜邏輯的替代方案嗎？
• 你考慮過把表驅動法做爲複雜繼承結構的替代方案嗎？
• 你考慮過把表數據存儲在外部並在運行期間讀入，以便在不修改代碼的狀況下就能夠改變這些數據嗎？
• 若是沒法用一種簡單的數組索引去訪問表，那麼你把機酸訪問鍵值的功能提取成單獨的子程序，而不是在代碼中重複地計算鍵值嗎？

通常控制問題

• 表達式中用的是true和false，而不是1和0嗎？
• 布爾值和true以及false作比較是隱式進行的嗎？
• 對數值作比較是顯式進行的嗎？
• 有沒有經過增長新的布爾變量，使用布爾函數和決策表來簡化表達式？
• 布爾表達式是用確定形式表達的嗎？
• 括號配對嗎？
• 在須要括號來明確的地方都使用括號了嗎
• 判斷是按照數軸順序編寫了嗎？
• 若是適當的話，java中的判斷用的是a.equals(b)方式，而沒有用a==b方式嗎？
• 空語句表述得明顯嗎？
• 用從新判斷部分條件，轉換成if-then-else或者case語句、把嵌套代碼提取成單獨的子程序、換成一種更面向對象的設計或者其餘的改進方法來簡化嵌套語句了嗎？
• 若是一個子程序的決策點超過10個，那麼能提出不從新設計的理由嗎？