代碼大全回顧篇...

看了很久代碼大全，最後全忘記了...留下的只是潛移默化的一些迷糊的東西，或許本書自己目的就在於此吧。不是要求程序員刻意按照每一個要求，只是爲寫代碼提供了一些基本準則。很不錯的一本書，提升寫代碼的修養。仍是給了我不少啓發。

• 從此更加規範的寫代碼
• 注意每一個細節
• 要作謙虛的程序員
• 想起了張無忌學太極拳

隱喻

隱喻經過把軟件開發與你所熟知的事情聯繫在一塊兒，從而使你對其有更深入的理解。 · 一些隱喻要好於其它隱喻。 · 把軟件建立與建造建築物類比，代表開發軟件前要精心準備，並代表了大規模項目與小 規模項目之間的差異。 · 認爲軟件開發實踐是智能工具箱中的工具進一步代表，每一個程序員都有許多本身的工 具，沒有任何一種工具是萬能的。爲每件工做選擇合適的工具，是成爲一個優秀程序員 的首要素質之一。

建立子程序

· 是否檢查過先決條件已經知足了? · 定義子程序將要解決的問題了嗎? · 結構設計是否足夠清楚，使得你能夠給子程序起個好名字? · 考慮過如何測試子程序了嗎? · 是否從模塊化水平或者知足時間和內存需求角度考慮過效率問題? · 是否查閱過參考書;以尋找有幫助的算法? · 是否用詳盡的 PDL 設計子程序? · 在必要時，是否在邏輯設計步驟前考慮了數據? · 是否檢查過PDL，它很容易理解嗎? · 是否注意到了足以使你返回到結構設計階段的警告(使用了全局數據，更適合其它子 程序的操做，等等)。 · 是否使用了PDL到代碼流程，是否把PDL做爲編碼基礎並把原有的PDL轉爲註釋? · 是否精確地把PDL翻譯成了代碼? · 在做出假設時，驗證它們了嗎? · 是從幾個設計方案中選擇了最好的，仍是隨意選擇了一個方案?

高質量的子程序

• 整體問題 · 建立子程序的理由充分嗎? · 若是把一個子程序中的某些部分獨立成另外一個子程序會更好的話，你這樣作了嗎? · 是否用了明顯而清楚的動賓詞組對過程進行命名?是不是用返回值的描述來命名函 數? · 子程序的名稱是否描述了它作的全部工做? · 子程序的內聚性是否是很強的功能內聚性?它只作一件工做並作得很好嗎? · 子程序的耦合是否是鬆散的?兩個子程序之間的聯繫是否是小規模、密切、可見和靈 活的? · 子程序的長度是否是它的功能和邏輯天然地決定的:而不是由人爲標準決定的?

• 防錯性編程 · 斷言是否用於驗證假設? · 子程序對於非法輸入數據進行防禦了嗎? · 子程序是否能很好地進行程序終止? · 子程序是否能很好地處理修改狀況? · 是否不用很麻煩地啓用或去掉調試幫助? · 是否信息隱蔽、鬆散耦合，以及使用「防火牆」數據檢查，以使得它不影響子程序之 外的代碼? 第五章 高質量子程序的特色 74 · 子程序是否檢查返回值? · 產品代碼中的防錯性代碼是否幫助用戶，而不是程序員?

• 參數傳遞問題 · 形式參數與實際參數匹配嗎? · 子程序中參數的排列合理嗎?與類似子程序中的參數排列順序匹配嗎? · 接口假設說明了嗎? · 子程序中參數個數是否是7個或者更少， · 是否只傳遞告終構化變量中另外一個子程序用獲得的部分? · 是否用到了每個輸入參數? · 是否用到了每個輸出參數? · 若是子程序是一函數，是否在全部狀況下它都會返回一個值?

模塊的質量

· 模塊是否有一箇中心目的? · 模塊是不是圍繞着一組公用數據進行組織的? · 模塊是否提供了一套相互聯繫的功能? · 模塊功能是否足夠完備，從而使得其它模塊沒必要干預其內部數據? · 一個模塊相對其它模塊是不是獨立的?它們之間是鬆散耦合的嗎? · 一個模塊的實現細節，對其它模塊來講，是隱含的嗎? · 模塊的接口是否抽象到了沒必要關心其功能實現方式的地步?它是做爲一個黑盒子來設 計的嗎? · 是否考慮過把模塊再劃分爲單元模塊?是否對其進行了充分的再劃分工做? · 若是用不徹底支持模塊的語言編程，你是否制定了編程約定以使這種語言支持模塊?

高層次設計

本表給出了在評估設計質量時，一般要考慮一些問題。本表是 3.4 節中結構設計檢查表的 補充，這個表所考慮的主要是設計質量。3.4 節中的檢查表則側重於結構設計和設計內容。這 個表中的某些內容是相互重合的。 · 是否使用了往返設計方法，應從幾個方案中選擇最好的，而不是首次嘗試就肯定方案。 · 每一個子程序的設計是否都和與其相關的子程序設計一致? · 設計中是否對在結構設計層次上發現但並未解決的問題做了充分說明? · 是否對把程序分解成對象或模塊的方法感到滿意? · 是否對把模塊分解成子程序的方法感到滿意? · 是否明肯定義了子程序的邊界? · 是不是按照相互做用最小的原則定義子程序的? · 設計是否充分利用了自頂向下和自底向上法? · 設計是否對問題域要素、用戶接口要素、任務管理要素和數據管理要素進行了區分? · 設計是智力上可管理的嗎? · 設計是低複雜性嗎? · 程序是很容易維護的嗎? · 設計是否將子程序之間的聯繫保持在最低限度? · 設計是否爲未來程序可能擴展做了準備? · 子程序是不是設計成能夠在其它系統中再使用的? · 低層次子程序是高扇入的嗎? · 是否絕大多數子程序都是低或中等程度扇出的? · 設計易於移植到其它環境嗎? · 設計是簡練的嗎?是否是全部部分都是必要的? · 設計是成層的嗎? · 設計中是否儘可能採用了標準化技術以免奇特的、難以理解的要素?

數據名稱

• 通用命名約定 · 變量名稱是否徹底準確地描述了變量表明的是什麼? · 變量名是否指向是客觀世界中的問題，而不是關於這問題的用程序語言表達解決方案? · 變量名稱是不是夠長，使得你沒必要破譯它? · 變量名中若是含有計算限定詞的話，是否將其放在最後? · 是否在名稱中用Count或Index來代替了Num?
• 對特殊類型數據的命名 · 循環變量的名稱是有意義的嗎?(若是循環體較長是嵌套循環的話，應用有含義的名 · · · 稱來代替 i、j、k 之類的名稱) 是否用更富於含義的名稱來代替了被叫做"tempotarg"的臨時變量? 當邏輯變量的值是"True"時，它的名稱是否充分表達了其含義? 是否用前綴或後綴來代表了某些枚舉類型是一類的?如用 Color 來做 ColorRed， ColorGreen，ColorBlue 等枚舉類型的前綴。 · 命名常量的名稱是不是指向它們表明的實體而不是它們所表明的數值的?
• 命名約定 · 命名約定是否區分了局部、模塊和全局數據? · 命名約定是否對類型名稱、命名常量、枚舉類型和變量進行了區分? · 在不支持強化僅供子程序輸入參數的語言中，命名約定是否對這類參數進行了標識? · 命名約定是否是與程序語言的標準約定儘量地相容? · 對於語言中沒有強制的子程序中僅作輸入的參數，是否約定將它標識了? · 是否對名稱進行了格式化以加強程序的可讀性? 短名稱 · 代碼是否使用了長名稱?(除非有必要使用短名稱) · 是否避免了只省略一個字母的縮寫? · 全部單詞保持縮寫的連續性了嗎? · 全部的名稱都是容易發音的嗎? · 是否避免了會引發錯誤發音的名稱? · 是否在註釋表中對短變量名進行了註釋?
• 避免以下這些常見的命名錯誤了嗎 · 易引發誤會的名稱 · 含義類似的名稱 · 僅有一或兩個字母不一樣的名稱 · 發音類似的名稱 · 使用數字的名稱 · 對單詞做改寫以使其比較短的名稱 · 英語中常拼寫錯的名稱 · 標準庫子程序或已定義的變量名又定義了 · 徹底是隨意的名稱 · 含有難以辨識字母的名稱

變量

• 通常數據 · 是否已經使變量的做用域儘量地小? · 是否把對變量的使用集中到了一塊兒? · 控制結構與數據結構是相對應的嗎? · 每一個變量是否有且僅有一個功能? · 每一個變量的含義都是明確的嗎?是否保證了每一個變量都沒有隱含的意義? · 每個說明過的變量都被用到了嗎?
• 全局變量 · 是不是在無可奈何的狀況下，才使某些變量成爲全局的? · 命名約定是否對局部、模塊和全局變量進行了區分? · 是否說明了全部全局變量? · 程序中是否不含有僞全局變量——傳往各個子程序的龐大而臃腫的數據結構? · 是否用存取子程序來代替了全局數據? · 是把存取子程序和數據組織成模塊而不是隨意歸成一堆的嗎? · 存取子程序的抽象層次是否超過了程序語言實現細節? · 全部相互有聯繫的存取子程序，其抽象程度都是一致的嗎?

基本數據

• 常數 • 代碼中是否避免了」奇異數」(常數?) • 程序中是否採起了措施來防止出現被「0」除錯誤? • 類型轉換是顯式進行的嗎? • 若是在同一個表達式中出現了兩種不一樣類型的變量，是否對錶達式按照你的意願進行 求值? • 程序中是否避免了混合類型比較? • 在編譯過程當中是沒有警告的嗎?
• 整型數 • 使用整型數相除表達式的結果是否與預期的一致? • 整型數表達式中是否避免了整型數溢出問題? 浮點數 • 是否避免了數量級相差過大的數之間加減運算? • 程序中是否系統地採起措施來防止舍入偏差問題? • 程序中是否避免了對浮點數進行相等比較? 字符和字符串 • 程序中是否避免了常數型字符和字符串? • 對字符串的引用是否避免了邊界錯誤? • 程序中是否使用了附加的邏輯變量來講明條件判斷? • 程序中是否使用了附加的邏輯變量來簡化條件判斷?
• 枚舉類型 • 程序中是否用枚舉類型代替了命名常量來改善可讀性、可靠性和易改動性? • 是否用了枚舉類型代替邏輯變量以改進可讀性和靈活性? • 在使用了枚舉類型的判斷中是否檢查了無效值? • 枚舉類型的第一個入口是不是保留爲無效的?
• 命名常量 • 在數聽說明中使用的是命名常量嗎? • 是否一致地使用了命名常量，而不是一下子使用命名常量，一下子使用數值?
• 數組 • 是否全部的下標都在數組界限以內? • 是否對數組全部的引用都沒有發生越界錯誤? • 多維數組的下標排列順序正確嗎? • 在嵌套循環中，做爲循環變量的數組下標是正確的嗎?是否出現了交叉錯誤?

順序控制

• 組織順序式程序代碼 · 把語句間的依賴關係表示得很清楚嗎? · 子程序名是否把依賴關係表示得很清楚? · 子程序的參數是否把依賴關係表示得很清楚? · 若代碼的依賴關係不清楚，用註釋註明了嗎? · 代碼能從上讀到下嗎? · 變量的出現靠得很近嗎? ——從跨度和存活時間來考慮。

條件控制

• 條件語句 if-then 語句 • 正常狀況路徑在代碼中流向是否很分明? • if-then 語句在出現等號時流向是否正確? • else 語句是否有必要? • else 語句正確嗎? • if 語句和 else 語句正確嗎?它們是否弄反了? • 正常狀況是否跟在 if 後而非 else 後? if-then-else 語句 • 複雜的條件是否封裝成布爾函數調用了? • 最多見狀況放在前面嗎? • 所有狀況都覆蓋住了嗎? • if-then-else 語句是最好的選擇嗎?——用 case 語句代替是否更好? case 語句 • 各狀況的安排次序有含義嗎? • 每種狀況對應的操做簡單嗎?——如須要調用別的子程序。 • case 語句中的變量有實際意義嗎?它是爲了用 case 語句而單純地定義出來的僞變量 嗎? • 缺省語句的用法是否合法(規範)? • 用缺省語句檢查和報告異常狀況嗎? • 在 C 語言中，每一狀況的結尾用了 break 了嗎?

循環

· 循環是從頂部進入的嗎? · 循環的初始化是靠近着循環頂部的嗎? · 循環是死循環仍是事件驅動循環?它的結構比諸如 for i := 1 to 9999 之類的更清楚嗎? · 是C的for循環嗎?循環頭包含了所有的循環控制條件了嗎? · 循環體用begin和end或相似的結構去標明以避免在修改時出錯了嗎? · 空循環仍是非空循環? · 把循環內務處理歸結到一塊兒了嗎?放在頭部仍是放在結尾了? · 循環是完成一個且僅完成一個功能嗎?(像一個子程序同樣) · 循環在全部可能狀況下都能退出嗎? · 循環的停止條件明顯嗎? · 若是是for循環，在循環體內有沒有改變控制變量而使循環強行退出? · 循環體內部用一個變量保留重要循環控制變量的值，而不在循環體外引用控制變量的 終值嗎? · 循環用了安全計數器了嗎? · 循環控制變量是整數類型嗎? · 循環控制變量是否有一個有含義的名字? · 避免了控制變量的衝突沒有? · 循環短到可一目瞭然地步了嗎?

佈局

• 簡述 · 格式化的本意是要顯示代碼的邏輯結構嗎? · 格式化的形式能始終一致嗎? · 格式化後使代碼易於維護嗎? · 格式化後改進了可讀性嗎?
• 控制結構 · begin-end 對中代碼避免再次縮排了嗎? · 一系列的塊結構用空行相互分隔了嗎? · 複雜的表達式格式化後可讀性加強了嗎? · 單條語句塊始終一致地格式化了嗎? · Case 語句的格式化與其它控制結構格式化相協調嗎? · goto 語句格式化後本身顯得更清楚了嗎?
• 單條語句 · 把單條語句分紅幾行，每行都明顯地不能做獨立行看待了嗎? · 續行有意識地退格了嗎? · 相關語句組對齊了嗎? · 不相關語句組不該對齊，你是這樣的嗎? · 每行至多含一條語句嗎? · 每一個語句避免反作用了嗎? · 數據定義時相應項對齊了嗎? · 每行至多定義一個數據，是嗎?
• 註釋 · 註釋行與它所對應的代碼退一樣格數了嗎? · 註釋行的形式易修改嗎?
• 子程序 · 子程序的參量格式化後各參數易讀、易修改、易加註釋嗎? · 在C中是否用新子程序定義方法呢? · Fortran 中，參數定義是否和局部變量定義分開?
• 文件、模塊和程序 · 若語言容許有多個源文件，每一個源文件僅含一個模塊是嗎? · 一個文件內的各子程序是否用空行清楚隔開? · 若是一個文件含幾個模塊，那麼每一個模塊中的子程序是否被組織到被清楚隔開? · 各子程序是否按字母順序排列?