代碼更清晰高效的一些經驗
當前位置:點晴教程→知識管理交流
→『 技術文檔交流 』
一、排版:
1、關鍵詞和操作符之間加適當的空格。 2、相對獨立的程序塊與塊之間加空行 3、較長的語句、表達式等要分成多行書寫。 4、劃分出的新行要進行適應的縮進,使排版整齊,語句可讀。 5、長表達式要在低優先級操作符處劃分新行,操作符放在新行之首。 6、循環、判斷等語句中若有較長的表達式或語句,則要進行適應的劃分。 7、若函數或過程中的參數較長,則要進行適當的劃分。 8、不允許把多個短語句寫在一行中,即一行只寫一條語句。 9、函數或過程的開始、結構的定義及循環、判斷等語句中的代碼都要采用縮進風格。 10、C/C++語言是用大括號‘{’和‘}’界定一段程序塊的,編寫程序塊時‘{’和‘}’應各獨占一行并且位于同一列,同時與引用它們的語句左 對齊。在函數體的開始、類的定義、結構的定義、枚舉的定義以及if、for、do、while、switch、case語句中的程序都要采用如上的縮進方 式。 二、注釋 1、注釋要簡單明了。 2、邊寫代碼邊注釋,修改代碼同時修改相應的注釋,以保證注釋與代碼的一致性。 3、在必要的地方注釋,注釋量要適中。注釋的內容要清楚、明了,含義準確,防止注釋二義性。保持注釋與其描述的代碼相鄰,即注釋的就近原則。 4、對代碼的注釋應放在其上方相鄰位置,不可放在下面。 5、對數據結構的注釋應放在其上方相鄰位置,不可放在下面;對結構中的每個域的注釋應放在此域的右方;同一結構中不同域的注釋要對齊。 6、變量、常量的注釋應放在其上方相鄰位置或右方。 7、全局變量要有較詳細的注釋,包括對其功能、取值范圍、哪些函數或過程存取它以及存取時注意事項等的說明。 8、在每個源文件的頭部要有必要的注釋信息,包括:文件名;版本號;作者;生成日期;模塊功能描述(如功能、主要算法、內部各部分之間的關系、該文件與其它文件關系等);主要函數或過程清單及本文件歷史修改記錄等。 9、在每個函數或過程的前面要有必要的注釋信息,包括:函數或過程名稱;功能描述;輸入、輸出及返回值說明;調用關系及被調用關系說明等。 三、命名 1、較短的單詞可通過去掉“元音”形成縮寫; 2、較長的單詞可取單詞的頭幾發符的優先級,并用括號明確表達式的操作順序,避免使用默認優先級。 3、使用匈牙利表示法 四、可讀性 1、避免使用不易理解的數字,用有意義的標識來替代。 2、不要使用難懂的技巧性很高的語句。 3、源程序中關系較為緊密的代碼應盡可能相鄰。 五、變量 1、去掉沒必要的公共變量。 2、構造僅有一個模塊或函數可以修改、創建,而其余有關模塊或函數只訪問的公共變量,防止多個不同模塊或函數都可以修改、創建同一公共變量的現象。 3、仔細定義并明確公共變量的含義、作用、取值范圍及公共變量間的關系。 4、明確公共變量與操作此公共變量的函數或過程的關系,如訪問、修改及創建等。 5、當向公共變量傳遞數據時,要十分小心,防止賦與不合理的值或越界等現象發生。 6、防止局部變量與公共變量同名。 7、仔細設計結構中元素的布局與排列順序,使結構容易理解、節省占用空間,并減少引起誤用現象。 8、結構的設計要盡量考慮向前兼容和以后的版本升級,并為某些未來可能的應用保留余地(如預留一些空間等)。 9、留心具體語言及編譯器處理不同數據類型的原則及有關細節。 10、嚴禁使用未經初始化的變量。聲明變量的同時對變量進行初始化。 11、編程時,要注意數據類型的強制轉換。 六、函數、過程 1、函數的規模盡量限制在200行以內。 2、一個函數最好僅完成一件功能。 3、為簡單功能編寫函數。 4、函數的功能應該是可以預測的,也就是只要輸入數據相同就應產生同樣的輸出。 5、盡量不要編寫依賴于其他函數內部實現的函數。 6、避免設計多參數函數,不使用的參數從接口中去掉。 7、用注釋詳細說明每個參數的作用、取值范圍及參數間的關系。 8、檢查函數所有參數輸入的有效性。 9、檢查函數所有非參數輸入的有效性,如數據文件、公共變量等。 10、函數名應準確描述函數的功能。 11、避免使用無意義或含義不清的動詞為函數命名 12、函數的返回值要清楚、明了,讓使用者不容易忽視錯誤情況。 13、明確函數功能,精確(而不是近似)地實現函數設計。 14、減少函數本身或函數間的遞歸調用。 15、編寫可重入函數時,若使用全局變量,則應通過關中斷、信號量(即P、V操作)等手段對其加以保護。 七、可測性 1、在編寫代碼之前,應預先設計好程序調試與測試的方法和手段,并設計好各種調測開關及相應測試代碼如打印函數等。 2、在進行集成測試/系統聯調之前,要構造好測試環境、測試項目及測試用例,同時仔細分析并優化測試用例,以提高測試效率。 八、程序效率 1、編程時要經常注意代碼的效率。 2、在保證軟件系統的正確性、穩定性、可讀性及可測性的前提下,提高代碼效率。 3、不能一味地追求代碼效率,而對軟件的正確性、穩定性、可讀性及可測性造成影響。 4、編程時,要隨時留心代碼效率;優化代碼時,要考慮周全。 5、要仔細地構造或直接用匯編編寫調用頻繁或性能要求極高的函數。 6、通過對系統數據結構劃分與組織的改進,以及對程序算法的優化來提高空間效率。 7、在多重循環中,應將最忙的循環放在最內層。 8、盡量減少循環嵌套層次。 9、避免循環體內含判斷語句,應將循環語句置于判斷語句的代碼塊之中。 10、盡量用乘法或其它方法代替除法,特別是浮點運算中的除法。 九、質量保證 1、在軟件設計過程中構筑軟件質量。代碼質量保證優先原則 (1)正確性,指程序要實現設計要求的功能。 (2)穩定性、安全性,指程序穩定、可靠、安全。 (3)可測試性,指程序要具有良好的可測試性。 (4)規范/可讀性,指程序書寫風格、命名規則等要符合規范。 (5)全局效率,指軟件系統的整體效率。 (6)局部效率,指某個模塊/子模塊/函數的本身效率。 (7)個人表達方式/個人方便性,指個人編程習慣。 2、只引用屬于自己的存貯空間。 3、防止引用已經釋放的內存空間。 4、過程/函數中分配的內存,在過程/函數退出之前要釋放。 5、過程/函數中申請的(為打開文件而使用的)文件句柄,在過程/函數退出前要關閉。 6、防止內存操作越界。 7、時刻注意表達式是否會上溢、下溢。 8、認真處理程序所能遇到的各種出錯情況。 9、系統運行之初,要初始化有關變量及運行環境,防止未經初始化的變量被引用。 10、系統運行之初,要對加載到系統中的數據進行一致性檢查。 11、嚴禁隨意更改其它模塊或系統的有關設置和配置。 12、不能隨意改變與其它模塊的接口。 13、充分了解系統的接口之后,再使用系統提供的功能。 14、要時刻注意易混淆的操作符。當編完程序后,應從頭至尾檢查一遍這些操作符。 15、不使用與硬件或操作系統關系很大的語句,而使用建議的標準語句。 16、建議:使用第三方提供的軟件開發工具包或控件時,要注意以下幾點: (1)充分了解應用接口、使用環境及使用時注意事項。 (2)不能過分相信其正確性。 (3)除非必要,不要使用不熟悉的第三方工具包與控件。 十、代碼編譯 1、編寫代碼時要注意隨時保存,并定期備份,防止由于斷電、硬盤損壞等原因造成代碼丟失。 2、同一項目組內,最好使用相同的編輯器,并使用相同的設置選項。 3、合理地設計軟件系統目錄,方便開發人員使用。 4、打開編譯器的所有告警開關對程序進行編譯。 5、在同一項目組或產品組中,要統一編譯開關選項。 6、使用工具軟件(如Visual SourceSafe)對代碼版本進行維護。 十一、代碼測試、維護 1、單元測試要求至少達到語句覆蓋。 2、單元測試開始要跟蹤每一條語句,并觀察數據流及變量的變化。 3、清理、整理或優化后的代碼要經過審查及測試。 4、代碼版本升級要經過嚴格測試。 該文章在 2010/8/13 17:56:26 編輯過 |
關鍵字查詢
相關文章
正在查詢... |