某公司程序培訓教材-資料下載頁

　　

【正文】 it_Point( void ){ = 10。 = 10。 /* 初始化“點”的坐標 */}189。 621：如果多段代碼重復做同一件事情，那么在函數的劃分上可能存在問題。說明：若此段代碼各語句之間有實質性關聯并且是完成同一件功能的，那么可考慮把此段代碼構造成一個新的函數。189。 622：功能不明確較小的函數，特別是僅有一個上級函數調用它時，應考慮把它合并到上級函數中，而不必單獨存在。說明：模塊中函數劃分的過多，一般會使函數間的接口變得復雜。所以過小的函數，特別是扇入很低的或功能不明確的函數，不值得單獨存在。189。 623：設計高扇入、合理扇出（小于7）的函數。說明：扇出是指一個函數直接調用（控制）其它函數的數目，而扇入是指有多少上級函數調用它。扇出過大，表明函數過分復雜，需要控制和協調過多的下級函數；而扇出過小，如總是1，表明函數的調用層次可能過多，這樣不利程序閱讀和函數結構的分析，并且程序運行時會對系統資源如堆棧空間等造成壓力。函數較合理的扇出（調度函數除外）通常是35。扇出太大，一般是由于缺乏中間層次，可適當增加中間層次的函數。扇出太小，可把下級函數進一步分解多個函數，或合并到上級函數中。當然分解或合并函數時，不能改變要實現的功能，也不能違背函數間的獨立性。扇入越大，表明使用此函數的上級函數越多，這樣的函數使用效率高，但不能違背函數間的獨立性而單純地追求高扇入。公共模塊中的函數及底層函數應該有較高的扇入。較良好的軟件結構通常是頂層函數的扇出較高，中層函數的扇出較少，而底層函數則扇入到公共模塊中。189。 624：減少函數本身或函數間的遞歸調用。說明：遞歸調用特別是函數間的遞歸調用（如ABCA），影響程序的可理解性；遞歸調用一般都占用較多的系統資源（如棧空間）；遞歸調用對程序的測試有一定影響。故除非為某些算法或功能的實現方便，應減少沒必要的遞歸調用。189。 625：仔細分析模塊的功能及性能需求，并進一步細分，同時若有必要畫出有關數據流圖，據此來進行模塊的函數劃分與組織。說明：函數的劃分與組織是模塊的實現過程中很關鍵的步驟，如何劃分出合理的函數結構，關系到模塊的最終效率和可維護性、可測性等。根據模塊的功能圖或/及數據流圖映射出函數結構是常用方法之一。189。 626：改進模塊中函數的結構，降低函數間的耦合度，并提高函數的獨立性以及代碼可讀性、效率和可維護性。優化函數結構時，要遵守以下原則：（1）不能影響模塊功能的實現。（2）仔細考查模塊或函數出錯處理及模塊的性能要求并進行完善。（3）通過分解或合并函數來改進軟件結構。（4）考查函數的規模，過大的要進行分解。（5）降低函數間接口的復雜度。（6）不同層次的函數調用要有較合理的扇入、扇出。（7）函數功能應可預測。（8）提高函數內聚。（單一功能的函數內聚最高）說明：對初步劃分后的函數結構應進行改進、優化，使之更為合理。189。 627：在多任務操作系統的環境下編程，要注意函數可重入性的構造。說明：可重入性是指函數可以被多個任務進程調用。在多任務操作系統中，函數是否具有可重入性是非常重要的，因為這是多個進程可以共用此函數的必要條件。另外，編譯器是否提供可重入函數庫，與它所服務的操作系統有關，只有操作系統是多任務時，編譯器才有可能提供可重入函數庫。如DOS下BC和MSC等就不具備可重入函數庫，因為DOS是單用戶單任務操作系統。189。 628：避免使用BOOL參數。說明：原因有二，其一是BOOL參數值無意義，TURE/FALSE的含義是非常模糊的，在調用時很難知道該參數到底傳達的是什么意思；其二是BOOL參數值不利于擴充。還有NULL也是一個無意義的單詞。189。 629： 對于提供了返回值的函數，在引用時最好使用其返回值。189。 630：當一個過程（函數）中對較長變量（一般是結構的成員）有較多引用時，可以用一個意義相當的宏代替。 說明：這樣可以增加編程效率和程序的可讀性。示例：在某過程中較多引用TheReceiveBuffer[FirstSocket].byDataPtr，則可以通過以下宏定義來代替： define pSOCKDATA TheReceiveBuffer[FirstScoket].byDataPtr7 可測性185。 71：在同一項目組或產品組內，要有一套統一的為集成測試與系統聯調準備的調測開關及相應打印函數，并且要有詳細的說明。說明：本規則是針對項目組或產品組的。185。 72：在同一項目組或產品組內，調測打印出的信息串的格式要有統一的形式。信息串中至少要有所在模塊名（或源文件名）及行號。說明：統一的調測信息格式便于集成測試。185。 73：編程的同時要為單元測試選擇恰當的測試點，并仔細構造測試代碼、測試用例，同時給出明確的注釋說明。測試代碼部分應作為（模塊中的）一個子模塊，以方便測試代碼在模塊中的安裝與拆卸（通過調測開關）。說明：為單元測試而準備。185。 74：在進行集成測試/系統聯調之前，要構造好測試環境、測試項目及測試用例，同時仔細分析并優化測試用例，以提高測試效率。說明：好的測試用例應盡可能模擬出程序所遇到的邊界值、各種復雜環境及一些極端情況等。185。 75：使用斷言來發現軟件問題，提高代碼可測性。說明：斷言是對某種假設條件進行檢查（可理解為若條件成立則無動作，否則應報告），它可以快速發現并定位軟件問題，同時對系統錯誤進行自動報警。斷言可以對在系統中隱藏很深，用其它手段極難發現的問題進行定位，從而縮短軟件問題定位時間，提高系統的可測性。實際應用時，可根據具體情況靈活地設計斷言。示例：下面是C語言中的一個斷言，用宏來設計的。（其中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 )。 abort( )。}define EXAM_ASSERT( condition ) if (condition) // 若條件成立，則無動作 NULL。 else // 否則報告 exam_assert( __FILE__, __LINE__ ) else // 若不使用斷言測試define EXAM_ASSERT(condition) NULL endif /* end of ASSERT */185。 76：用斷言來檢查程序正常運行時不應發生但在調測時有可能發生的非法情況。185。 77：不能用斷言來檢查最終產品肯定會出現且必須處理的錯誤情況。說明：斷言是用來處理不應該發生的錯誤情況的，對于可能會發生的且必須處理的情況要寫防錯程序，而不是斷言。如某模塊收到其它模塊或鏈路上的消息后，要對消息的合理性進行檢查，此過程為正常的錯誤檢查，不能用斷言來實現。185。 78：對較復雜的斷言加上明確的注釋。說明：為復雜的斷言加注釋，可澄清斷言含義并減少不必要的誤用。185。 79：用斷言確認函數的參數。示例：假設某函數參數中有一個指針，那么使用指針前可對它檢查，如下。int exam_fun( unsigned char *str ){ EXAM_ASSERT( str != NULL )。 // 用斷言檢查“假設指針不為空”這個條件 ... //other program code}185。 710：用斷言保證沒有定義的特性或功能不被使用。示例：假設某通信模塊在設計時，準備提供“無連接”和“連接” 這兩種業務。但當前的版本中僅實現了“無連接”業務，且在此版本的正式發行版中，用戶（上層模塊）不應產生“連接”業務的請求，那么在測試時可用斷言檢查用戶是否使用“連接”業務。如下。define EXAM_CONNECTIONLESS 0 // 無連接業務define EXAM_CONNECTION 1 // 連接業務int msg_process( EXAM_MESSAGE *msg ){ unsigned char service。 /* message service class */ EXAM_ASSERT( msg != NULL )。service = get_msg_service_class( msg )。 EXAM_ASSERT( service != EXAM_CONNECTION )。 // 假設不使用連接業務 ... //other program code}185。 711：用斷言對程序開發環境（OS/Compiler/Hardware）的假設進行檢查。說明：程序運行時所需的軟硬件環境及配置要求，不能用斷言來檢查，而必須由一段專門代碼處理。用斷言僅可對程序開發環境中的假設及所配置的某版本軟硬件是否具有某種功能的假設進行檢查。如某網卡是否在系統運行環境中配置了，應由程序中正式代碼來檢查；而此網卡是否具有某設想的功能，則可由斷言來檢查。對編譯器提供的功能及特性假設可用斷言檢查，原因是軟件最終產品（即運行代碼或機器碼）與編譯器已沒有任何直接關系，即軟件運行過程中（注意不是編譯過程中）不會也不應該對編譯器的功能提出任何需求。示例：用斷言檢查編譯器的int型數據占用的內存空間是否為2，如下。EXAM_ASSERT( sizeof( int ) == 2 )。185。 712：正式軟件產品中應把斷言及其它調測代碼去掉（即把有關的調測開關關掉）。說明：加快軟件運行速度。185。 713：在軟件系統中設置與取消有關測試手段，不能對軟件實現的功能等產生影響。說明：即有測試代碼的軟件和關掉測試代碼的軟件，在功能行為上應一致。185。 714：用調測開關來切換軟件的DEBUG版和正式版，而不要同時存在正式版本和DEBUG版本的不同源文件，以減少維護的難度。185。 715：軟件的DEBUG版本和發行版本應該統一維護，不允許分家，并且要時刻注意保證兩個版本在實現功能上的一致性。189。 71：在編寫代碼之前，應預先設計好程序調試與測試的方法和手段，并設計好各種調測開關及相應測試代碼如打印函數等。說明：程序的調試與測試是軟件生存周期中很重要的一個階段，如何對軟件進行較全面、高率的測試并盡可能地找出軟件中的錯誤就成為很關鍵的問題。因此在編寫源代碼之前，除了要有一套比較完善的測試計劃外，還應設計出一系列代碼測試手段，為單元測試、集成測試及系統聯調提供方便。189。 72：調測開關應分為不同級別和類型。說明：調測開關的設置及分類應從以下幾方面考慮：針對模塊或系統某部分代碼的調測；針對模塊或系統某功能的調測；出于某種其它目的，如對性能、容量等的測試。這樣做便于軟件功能的調測，并且便于模塊的單元測試、系統聯調等。189。 73：編寫防錯程序，然后在處理錯誤之后可用斷言宣布發生錯誤。示例：假如某模塊收到通信鏈路上的消息，則應對消息的合法性進行檢查，若消息類別不是通信協議中規定的，則應進行出錯處理，之后可用斷言報告，如下例。ifdef _EXAM_ASSERT_TEST_ // 若使用斷言測試/* Notice: this function does not call 39。abort39。 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 )。}define ASSERT_REPORT( condition ) if ( condition ) // 若條件成立，則無動作 NULL。 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。 ... // 其它合法消息處理 default: ... // 消息出錯處理 ASSERT_REPORT( FALSE )。 // “合法”消息不成立，報告 return MSG_HANDLE_ERROR。 }}8 程序效率185。 81：編程時要經常注意代碼的效率。說明：代碼效率分為全局效率、局部效率、時間效率及空間效率。全局效率是站在整個系統的角度上的系統效率；局部效率是站在模塊或函數角度上的效率；時間效率是程序處理輸入任務所需的時間長短；空間效率是程序所需內存空間，如機器代碼空間大小、數據空間大小、棧空間大小等。185。 82：在保證軟件系統的正確性、穩定性、可讀性及可測性的前提下，提高代碼效率。說明：不能一味地追求代碼效率，而對軟件的