1． 致命的異常中止決不允許。
2． 以這個次序編寫：用戶手冊，說明書，幫助，源代碼。
3． 除非你使用Risk Factor Analysis(RFA), 否則一個程序將花費雙倍你認為開發(fā)所需的時間。
4． 編碼工作量應該不超過開發(fā)工作的百分之二十。
5． 測試應該至少要占工程的百分之三十。
6． 注釋應該至少要占源代碼的百分之二十。
7． 一條錯誤的消息應該報告什么發(fā)生了，關于這個用戶能夠做什么，程序下一步要做什么，以及那一行代碼造成該問題?可能也要注意時間，用戶名和環(huán)境。
8． 好的程序將自動地發(fā)送最近的錯誤信息給永久性媒體。
9． 調用一個例程三次？隱藏它調用一次？不要隱藏。
10． 例程精確地只需要一個入口和一個出口例外包括了菜單和錯誤陷阱。
11． 帶有清晰的變量名和例程名的文檔代碼。
12． 數(shù)據(jù)庫應該是相關的。
13． 總是采用最好的算法。
14． 首先優(yōu)化最慢的例程，使用Profiler標示它們。
15． 最好的開發(fā)語言通常是具有最短開發(fā)時間的那個。
16． 要求顧客簽名。
17． 首先編寫更具風險的模塊。
18． 讓簡單的維護成為你的燈光。
19． 檢查你寫的每個簽名和拼寫。
20． 不要寫任何你能夠用一個3*5卡片封面復制的程序。
21． 知道何時應該完成何事。
22． 沒有任何列表是完善的。
23． 困難不是你正在看之處。
24． 存在的規(guī)則和規(guī)律可以讓人免于思考。
（摘于《Java 程序調試實用手冊》p342）
本站僅提供存儲服務，所有內容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權內容，請
點擊舉報。
