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





· 程序的名字讓人困惑。Handlestuff（）能告訴我們程序是干什么的嗎？
· 程序沒有被說明（關于說明的問題已經超出了個別子程序的范圍，詳見第19章“自我說明的子程序”）。
· 子程序的布局不好。代碼的物理組織形式幾乎沒有給出其邏輯組織形式的任何信息。
布局的使用過于隨心所欲，程序每一部分的布局都是不一樣的。關于這一點。只要比較一下ExpenseType=2 和ExpenseType=3 兩個地方的風格就清楚了（關于布局問題，詳見第十八章“布局與風格”）。
· 子程序的輸入變量值InPutRec 被改變過。如果它作為輸入變量，那它的值就不該變化。如果要變化它的值，就不該稱之為輸入變量InputRec。
· 子程序進行了全局變量的讀寫操作。它從CorpExpense 中讀入變量并寫給Profit。它應該與存取子程序通信，而不應直接讀寫全局變量。
· 這個子程序的功用不是單一的。它初始化了某些變量。對一個數據庫進行寫操作，又進行了某些計算工作，而它們又看不出任何聯系。一個子程序的功用應該是單一，明了的。
· 子程序中沒有采取預防非法數據的措施。如果CrntQtr的值為“0”，那么，表達式YTDRevenue*4.0／real(CrntQtr)就會出現被零除的錯誤。
· 程序中使用了幾個常數：100, 4.0, 12, 2和3。關于“神秘”（magic）數的問題見11.1節“常數”
第五章高質量子程序的特點47
· 在程序中僅使用了域的CORP_DATA 型參數的兩個域。如果僅僅使用兩個域，那就該僅僅傳入特定的域而不是整個結構化變量。
· 子程序中的一些參數沒有使用過。ScreenX 和ScreenY 在程序中沒有涉及。
· 程序中的一個參數被錯誤標定了。PrevColor被標定為變量型參數，然而在程序中又沒有對其賦值。
· 程序中的參數太多。程序中參數個數的合理上限應該是七個左右。而這個程序中則多達11個。程序中的參數多得怕人，恐怕沒誰會仔細檢查它們，而且連數一下都不愿意。