看了好久程式碼大全，最後全忘記了...留下的只是潛移默化的一些迷糊的東西，或許本書本身目的就在於此吧。不是要求程式設計師刻意按照每個要求，只是為寫程式碼提供了一些基本準則。很不錯的一本書，提高寫程式碼的修養。還是給了我很多啟發。
- 今後更加規範的寫程式碼
- 注意每個細節
- 要做謙虛的程式設計師
- 想起了張無忌學太極拳
隱喻
隱喻通過把軟體開發與你所熟知的事情聯絡在一起，從而使你對其有更深刻的理解。 · 一些隱喻要好於其它隱喻。 · 把軟體建立與建造建築物類比，表明開發軟體前要精心準備，並表明了大規模專案與小 規模專案之間的差別。 · 認為軟體開發實踐是智慧工具箱中的工具進一步表明，每個程式設計師都有許多自己的工 具，沒有任何一種工具是萬能的。為每件工作選擇合適的工具，是成為一個優秀程式設計師 的首要素質之一。
建立子程式
· 是否檢查過先決條件已經滿足了? · 定義子程式將要解決的問題了嗎? · 結構設計是否足夠清楚，使得你可以給子程式起個好名字? · 考慮過如何測試子程式了嗎? · 是否從模組化水平或者滿足時間和記憶體需求角度考慮過效率問題? · 是否查閱過參考書;以尋找有幫助的演算法? · 是否用詳盡的 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 中，引數定義是否和區域性變數定義分開?
- 檔案、模組和程式 · 若語言允許有多個原始檔，每個原始檔僅含一個模組是嗎? · 一個檔案內的各子程式是否用空行清楚隔開? · 如果一個檔案含幾個模組，那麼每個模組中的子程式是否被組織到被清楚隔開? · 各子程式是否按字母順序排列?