【正文】 82：在保證軟件系統(tǒng)的正確性、穩(wěn)定性、可讀性及可測性的前提下，提高代碼效率。全局效率是站在整個系統(tǒng)的角度上的系統(tǒng)效率；局部效率是站在模塊或函數角度上的效率；時間效率是程序處理輸入任務所需的時間長短；空間效率是程序所需內存空間，如機器代碼空間大小、數據空間大小、?？臻g大小等。 81：編程時要經常注意代碼的效率。 // “合法”消息不成立，報告 return MSG_HANDLE_ERROR。 else // 否則報告 assert_report ( __FILE__, __LINE__ ) else // 若不使用斷言測試define ASSERT_REPORT( condition ) NULL endif /* end of ASSERT */int msg_handle( unsigned char msg_name, unsigned char * msg ){ switch( msg_name ) { case MSG_ONE: ... // 消息MSG_ONE處理 return MSG_HANDLE_SUCCESS。 to exit program */void assert_report( char * file_name, unsigned int line_no ){ printf( \n[EXAM]Error Report: %s, line %u\n, file_name, line_no )。ifdef _EXAM_ASSERT_TEST_ // 若使用斷言測試/* Notice: this function does not call 39。 73：編寫防錯程序，然后在處理錯誤之后可用斷言宣布發(fā)生錯誤。這樣做便于軟件功能的調測，并且便于模塊的單元測試、系統(tǒng)聯調等。 72：調測開關應分為不同級別和類型。因此在編寫源代碼之前，除了要有一套比較完善的測試計劃外，還應設計出一系列代碼測試手段，為單元測試、集成測試及系統(tǒng)聯調提供方便。 71：在編寫代碼之前，應預先設計好程序調試與測試的方法和手段，并設計好各種調測開關及相應測試代碼如打印函數等。 715：軟件的DEBUG版本和發(fā)行版本應該統(tǒng)一維護，不允許分家，并且要時刻注意保證兩個版本在實現功能上的一致性。 714：用調測開關來切換軟件的DEBUG版和正式版，而不要同時存在正式版本和DEBUG版本的不同源文件，以減少維護的難度。說明：即有測試代碼的軟件和關掉測試代碼的軟件，在功能行為上應一致。185。 712：正式軟件產品中應把斷言及其它調測代碼去掉（即把有關的調測開關關掉）。EXAM_ASSERT( sizeof( int ) == 2 )。對編譯器提供的功能及特性假設可用斷言檢查，原因是軟件最終產品（即運行代碼或機器碼）與編譯器已沒有任何直接關系，即軟件運行過程中（注意不是編譯過程中）不會也不應該對編譯器的功能提出任何需求。用斷言僅可對程序開發(fā)環(huán)境中的假設及所配置的某版本軟硬件是否具有某種功能的假設進行檢查。 711：用斷言對程序開發(fā)環(huán)境（OS/Compiler/Hardware）的假設進行檢查。 EXAM_ASSERT( service != EXAM_CONNECTION )。 /* message service class */ EXAM_ASSERT( msg != NULL )。如下。示例：假設某通信模塊在設計時，準備提供“無連接”和“連接” 這兩種業(yè)務。 // 用斷言檢查“假設指針不為空”這個條件 ... //other program code}185。示例：假設某函數參數中有一個指針，那么使用指針前可對它檢查，如下。185。 78：對較復雜的斷言加上明確的注釋。如某模塊收到其它模塊或鏈路上的消息后，要對消息的合理性進行檢查，此過程為正常的錯誤檢查，不能用斷言來實現。 77：不能用斷言來檢查最終產品肯定會出現且必須處理的錯誤情況。 76：用斷言來檢查程序正常運行時不應發(fā)生但在調測時有可能發(fā)生的非法情況。}define EXAM_ASSERT( condition ) if (condition) // 若條件成立，則無動作 NULL。（其中NULL為0L）ifdef _EXAM_ASSERT_TEST_ // 若使用斷言測試void exam_assert( char * file_name, unsigned int line_no ){ printf( \n[EXAM]Assert failed: %s, line %u\n, file_name, line_no )。實際應用時，可根據具體情況靈活地設計斷言。說明：斷言是對某種假設條件進行檢查（可理解為若條件成立則無動作，否則應報告），它可以快速發(fā)現并定位軟件問題，同時對系統(tǒng)錯誤進行自動報警。185。 74：在進行集成測試/系統(tǒng)聯調之前，要構造好測試環(huán)境、測試項目及測試用例，同時仔細分析并優(yōu)化測試用例，以提高測試效率。說明：為單元測試而準備。 73：編程的同時要為單元測試選擇恰當的測試點，并仔細構造測試代碼、測試用例，同時給出明確的注釋說明。說明：統(tǒng)一的調測信息格式便于集成測試。 72：在同一項目組或產品組內，調測打印出的信息串的格式要有統(tǒng)一的形式。說明：本規(guī)則是針對項目組或產品組的。示例：在某過程中較多引用TheReceiveBuffer[FirstSocket].byDataPtr，則可以通過以下宏定義來代替： define pSOCKDATA TheReceiveBuffer[FirstScoket].byDataPtr7 可測性185。 630：當一個過程（函數）中對較長變量（一般是結構的成員）有較多引用時，可以用一個意義相當的宏代替。 629： 對于提供了返回值的函數，在引用時最好使用其返回值。還有NULL也是一個無意義的單詞。 628：避免使用BOOL參數。如DOS下BC和MSC等就不具備可重入函數庫，因為DOS是單用戶單任務操作系統(tǒng)。在多任務操作系統(tǒng)中，函數是否具有可重入性是非常重要的，因為這是多個進程可以共用此函數的必要條件。 627：在多任務操作系統(tǒng)的環(huán)境下編程，要注意函數可重入性的構造。（單一功能的函數內聚最高）說明：對初步劃分后的函數結構應進行改進、優(yōu)化，使之更為合理。（7）函數功能應可預測。（5）降低函數間接口的復雜度。（3）通過分解或合并函數來改進軟件結構。優(yōu)化函數結構時，要遵守以下原則：（1）不能影響模塊功能的實現。189。說明：函數的劃分與組織是模塊的實現過程中很關鍵的步驟，如何劃分出合理的函數結構，關系到模塊的最終效率和可維護性、可測性等。189。說明：遞歸調用特別是函數間的遞歸調用（如ABCA），影響程序的可理解性；遞歸調用一般都占用較多的系統(tǒng)資源（如棧空間）；遞歸調用對程序的測試有一定影響。189。公共模塊中的函數及底層函數應該有較高的扇入。當然分解或合并函數時，不能改變要實現的功能，也不能違背函數間的獨立性。扇出太大，一般是由于缺乏中間層次，可適當增加中間層次的函數。扇出過大，表明函數過分復雜，需要控制和協(xié)調過多的下級函數；而扇出過小，如總是1，表明函數的調用層次可能過多，這樣不利程序閱讀和函數結構的分析，并且程序運行時會對系統(tǒng)資源如堆棧空間等造成壓力。 623：設計高扇入、合理扇出（小于7）的函數。所以過小的函數，特別是扇入很低的或功能不明確的函數，不值得單獨存在。 622：功能不明確較小的函數，特別是僅有一個上級函數調用它時，應考慮把它合并到上級函數中，而不必單獨存在。說明：若此段代碼各語句之間有實質性關聯并且是完成同一件功能的，那么可考慮把此段代碼構造成一個新的函數。 /* 初始化“點”的坐標 */}189。 /* 初始化矩形的長與寬 */}void Init_Point( void ){ = 10。應如下分為兩個函數：void Init_Rect( void ){ = 0。 = 10。 = 0。示例：如下函數就是一種隨機內聚。在編程時，經常遇到在不同函數中使用相同的代碼，許多開發(fā)人員都愿把這些代碼提出來，并構成一個新函數。隨機內聚給函數或過程的維護、測試及以后的升級等造成了不便，同時也使函數或過程的功能不明確。說明：防止函數或過程內出現隨機內聚。189。 619：避免函數中不必要語句，防止程序中的垃圾代碼。說明：因為數據類型轉換或多或少存在危險。189。189。189。建議615：函數的返回值要清楚、明了，讓使用者不容易忽視錯誤情況。建議614：避免使用無意義或含義不清的動詞為函數命名。int input_record( void ) 。示例：參照如下方式命名函數。 613：使用動賓詞組為執(zhí)行某操作的函數命名。 612：函數名應準確描述函數的功能。函數在使用輸入之前，應進行必要的檢查。 611：檢查函數所有非參數輸入的有效性，如數據文件、公共變量等。 610：檢查函數所有參數輸入的有效性。}int sub( int a, int b ) { return (a