版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領
文檔簡介
1、軟件開發(fā)流程規(guī)范V1.0德聯(lián)軟件有限責任公司編制人: 侯秀美 審核人: 2015 年 8 月 19 日目錄 TOC o 1-3 h z u HYPERLINK l _Toc471739078 目錄 PAGEREF _Toc471739078 h 0 HYPERLINK l _Toc471739079 一、概述 PAGEREF _Toc471739079 h 2 HYPERLINK l _Toc471739080 二、開發(fā)流程規(guī)范 PAGEREF _Toc471739080 h 3 HYPERLINK l _Toc471739081 2.1 系統(tǒng)軟硬件開發(fā)環(huán)境 PAGEREF _Toc47173
2、9081 h 3 HYPERLINK l _Toc471739082 2.2 系統(tǒng)架構(系統(tǒng)組成) PAGEREF _Toc471739082 h 5 HYPERLINK l _Toc471739083 2.3 系統(tǒng)功能模塊設計 PAGEREF _Toc471739083 h 6 HYPERLINK l _Toc471739084 2.4 系統(tǒng)功能開發(fā)流程圖 PAGEREF _Toc471739084 h 6 HYPERLINK l _Toc471739085 2.5 開發(fā)修改記錄 PAGEREF _Toc471739085 h 7 HYPERLINK l _Toc471739086 三、開發(fā)
3、代碼規(guī)范 PAGEREF _Toc471739086 h 8 HYPERLINK l _Toc471739087 3.1 文件結構 PAGEREF _Toc471739087 h 8 HYPERLINK l _Toc471739088 3.1.1 文件信息聲明 PAGEREF _Toc471739088 h 8 HYPERLINK l _Toc471739089 3.1.2 頭文件的結構 PAGEREF _Toc471739089 h 10 HYPERLINK l _Toc471739090 3.1.3 定義文件的結構 PAGEREF _Toc471739090 h 11 HYPERLINK
4、l _Toc471739091 3.1.4 頭文件的作用 PAGEREF _Toc471739091 h 12 HYPERLINK l _Toc471739092 3.1.5 目錄結構 PAGEREF _Toc471739092 h 13 HYPERLINK l _Toc471739093 3.2 命名規(guī)則 PAGEREF _Toc471739093 h 13 HYPERLINK l _Toc471739094 3.2.1 共性原則 PAGEREF _Toc471739094 h 13 HYPERLINK l _Toc471739095 3.2.2 Windows變量命名規(guī)則 PAGEREF
5、_Toc471739095 h 14 HYPERLINK l _Toc471739096 3.3 程序風格 PAGEREF _Toc471739096 h 16 HYPERLINK l _Toc471739097 3.3.1 空行 PAGEREF _Toc471739097 h 17 HYPERLINK l _Toc471739098 3.3.2 代碼行 PAGEREF _Toc471739098 h 18 HYPERLINK l _Toc471739099 3.3.3 代碼行內的空格 PAGEREF _Toc471739099 h 19 HYPERLINK l _Toc471739100 3
6、.3.4 對齊 PAGEREF _Toc471739100 h 20 HYPERLINK l _Toc471739101 3.3.5 長行拆分 PAGEREF _Toc471739101 h 22 HYPERLINK l _Toc471739102 3.3.6 修飾符的位置 PAGEREF _Toc471739102 h 23 HYPERLINK l _Toc471739103 3.3.7 注釋 PAGEREF _Toc471739103 h 23 HYPERLINK l _Toc471739104 3.4 函數(shù)設計 PAGEREF _Toc471739104 h 26 HYPERLINK l
7、 _Toc471739105 3.4.1 參數(shù)的規(guī)則 PAGEREF _Toc471739105 h 26 HYPERLINK l _Toc471739106 3.4.2 返回值的規(guī)則 PAGEREF _Toc471739106 h 27 HYPERLINK l _Toc471739107 3.4.3 函數(shù)內部實現(xiàn)的規(guī)則 PAGEREF _Toc471739107 h 30 HYPERLINK l _Toc471739108 3.4.4 其它建議 PAGEREF _Toc471739108 h 32 HYPERLINK l _Toc471739109 3.4.5 使用斷言 PAGEREF _T
8、oc471739109 h 32 HYPERLINK l _Toc471739110 3.4.6 引用與指針的比較 PAGEREF _Toc471739110 h 33 HYPERLINK l _Toc471739111 3.5 變量類型定義 PAGEREF _Toc471739111 h 35 HYPERLINK l _Toc471739112 四、軟件測試規(guī)范 PAGEREF _Toc471739112 h 36 HYPERLINK l _Toc471739113 4.1 單元測試 PAGEREF _Toc471739113 h 36 HYPERLINK l _Toc471739114 4
9、.2 系統(tǒng)測試 PAGEREF _Toc471739114 h 37 HYPERLINK l _Toc471739115 4.6 業(yè)務測試 PAGEREF _Toc471739115 h 38 HYPERLINK l _Toc471739116 4.7 驗收測試 PAGEREF _Toc471739116 h 38 HYPERLINK l _Toc471739117 4.8 用戶現(xiàn)場測試 PAGEREF _Toc471739117 h 38 HYPERLINK l _Toc471739118 五、軟件版本管理 PAGEREF _Toc471739118 h 39 HYPERLINK l _To
10、c471739119 4.1版本管理的必要性 PAGEREF _Toc471739119 h 39一、概述本文制定煙臺開發(fā)區(qū)德聯(lián)軟件有限責任公司計算機軟件開發(fā)規(guī)范文檔。本規(guī)范的目的是使公司軟件開發(fā)項目階段清晰、要求明確、任務具體、編寫的代碼規(guī)范,使之規(guī)范化、系統(tǒng)化和工程化,向公司內從事軟件開發(fā)的工程師和管理人員提出一系列規(guī)范和要求,從而有利于開發(fā)過程的控制和管理,提高所開發(fā)軟件系統(tǒng)的質量,縮短開發(fā)時間,減少開發(fā)和維護費用,以保證項目高質量、順利進行。本規(guī)范包含:開發(fā)流程規(guī)范和開發(fā)代碼規(guī)范等,開發(fā)流程規(guī)范需要技術開發(fā)人員編寫相關內容,希望每個技術人員形成習慣,如有新的內容更新會及時通知大家,如有
11、好的規(guī)范要求也可通知編制人員及時更新。本規(guī)范為煙臺開發(fā)區(qū)德聯(lián)軟件有限責任公司內部材料,嚴禁其他商業(yè)應用。二、開發(fā)流程規(guī)范接受開發(fā)任務,詳細閱讀軟件技術規(guī)范或技術文檔,如對技術文檔有疑義或者不清楚的地方及時與項目總工或用戶溝通,根據(jù)文檔和溝通內容編寫項目開發(fā)計劃,必須包括但不限于系統(tǒng)軟硬件開發(fā)環(huán)境、系統(tǒng)架構、系統(tǒng)功能模塊設計、系統(tǒng)功能開發(fā)流程圖、開發(fā)修改記錄。2.1 系統(tǒng)軟硬件開發(fā)環(huán)境開發(fā)環(huán)境的搭建,最好形成文檔,便于以后同樣工作的使用。開發(fā)人員要明確系統(tǒng)開發(fā)擬采用的數(shù)據(jù)庫、操作系統(tǒng)、開發(fā)語言、開發(fā)工具、服務器等(具體到版本)。明確整個系統(tǒng)開發(fā)工作流程,至少應該包括以下流程。2.2 系統(tǒng)架構(系
12、統(tǒng)組成)確定系統(tǒng)整體體系架構,各層次之間的數(shù)據(jù)流的連接,確定軟件服務器的硬件配置及用戶硬件資源配置, 確定與用戶軟件平臺的統(tǒng)一協(xié)調。 開發(fā)人員在繪制架構圖時給出基本框架,能反映出基本意義即可,可以直接用文字代替例子中的圖片。圖1 系統(tǒng)邏輯架構圖舉例圖2 物理架構圖舉例2.3 系統(tǒng)功能模塊設計給出系統(tǒng)的主要功能模塊,每個模塊所包含的功能。圖3 圖書管理系統(tǒng)模塊規(guī)劃圖舉例2.4 系統(tǒng)功能開發(fā)流程圖給出系統(tǒng)主要功能的業(yè)務流程圖。圖4 系統(tǒng)功能業(yè)務流程圖舉例2.5 開發(fā)修改記錄1. 開發(fā)代碼做好備份(可以在完成一個重大功能之后,或者按時間周期性進行備份),以免由于不可抗力導致代碼不可修復。2.在每次重
13、大修改之后要做好記錄(改動的具體細節(jié)),修改前的版本要及時備份,可以方面隨時還原系統(tǒng)。修改日期修改內容是否備份備注三、開發(fā)代碼規(guī)范在研究項目團隊協(xié)作開發(fā)的情況下(這里的團隊協(xié)作也適合于應用項目的開發(fā)),編程時應該強調的一個重要方面是程序的易讀性,在保證軟件速度等性能指標能滿足用戶需求的情況下,能讓其他程序員容易讀懂你所編寫的程序。若研究項目小組的所有開發(fā)人員都遵循統(tǒng)一的、鮮明的一套編程風格,可以讓協(xié)作者、后繼者和自己一目了然,在很短的時間內看清楚程序結構,理解設計的思路,大大提高代碼的可讀性、可重用性、程序健壯性、可移植性、可維護性。制定本編程規(guī)范的目的是為了提高軟件開發(fā)效率及所開發(fā)軟件的可維
14、護性,提高軟件的質量。本規(guī)范由程序風格、命名規(guī)范、注釋規(guī)范、程序健壯性、可移植性、錯誤處理以及軟件的模塊化規(guī)范等部分組成。此規(guī)范以C/C+程序設計討論。3.1 文件結構每個C+/C程序通常分為兩個文件。一個文件用于保存程序的聲明(declaration),稱為頭文件。另一個文件用于保存程序的實現(xiàn)(implementation),稱為定義(definition)文件。C+/C程序的頭文件以“.h”為后綴,C程序的定義文件以“.c”為后綴,C+程序的定義文件通常以“.cpp”為后綴(也有一些系統(tǒng)以“.cc”或“.cxx”為后綴)。3.1.1 文件信息聲明文件信息聲明位于頭文件和定義文件的開頭(參見
15、示例3-1),主要內容有:(1) 版權信息;(2) 文件名稱,項目代碼,摘要,參考文獻;(3) 當前版本號,作者/修改者,完成日期;(4) 版本歷史信息;(5) 主要函數(shù)描述。/ Copyright (c) 2015, DeLianSoftCompany YanTai/ All rights reserved./ Filename :filename.h/ Project Code :The project code about this file/ Abstract :Describe the content of this file summarily/ Reference :/ Vers
16、ion :1.1/ Author :the name of author(mender)/ Accomplished date : September 2, 2004/ Replaced version : 1.0 / Original Author : the name of original author(mender)/ Accomplished date : September 10, 2003/ Main functions :/Function 1 Return code Function name(Parameter Explain)/Function 2 Return code
17、 Function name(Parameter Explain)/./Function n Return code Function name(Parameter Explain)/示例3-1 文件信息聲明 【規(guī)則3.1-1】文件信息聲明以兩行斜杠開始,以兩行斜杠結束,每一行都以兩個斜杠開始; 【規(guī)則3.1-2】文件信息聲明包含五個部分,各部分之間以一空行間隔; 【規(guī)則3.1-3】在主要函數(shù)部分描述了文件所包含的主要函數(shù)的聲明信息,如果是頭文件,這一部分是可以省略的。3.1.2 頭文件的結構頭文件由三部分內容組成: (1) 頭文件開頭處的文件信息聲明(參見示例3-1);(2) 預處理塊;(3
18、) 函數(shù)和類結構聲明等。假設頭文件名稱為 filesystem.h,頭文件的結構參見示例3-2。 【規(guī)則3.2-1】為了防止頭文件被重復引用,應當用ifndef/define/endif結構產生預處理塊;“#ifndef”或者“#define”后以TAB鍵代替SPACE鍵做空格;如果頭文件名稱是由多個單詞組成,則各單詞間以下劃線“_”連接,例如有頭文件名稱為“filesystem.h”,則定義如下:“#ifndef_FILE_SYSTEM_H_”; 【規(guī)則3.2-2】用 #include 格式來引用標準庫的頭文件(編譯器將從標準庫目錄開始搜索); 【規(guī)則3.2-3】用 #include “fi
19、lename.h” 格式來引用非標準庫的頭文件(編譯器將從用戶的工作目錄開始搜索); 【建議3.2-1】頭文件中只存放“聲明”而不存放“定義”; 【建議3.2-1】頭文件中應包含所有定義文件所定義的函數(shù)聲明,如果一個頭文件對應多個定義文件,則不同定義文件內實現(xiàn)的函數(shù)要分開聲明,并作注釋以解釋所聲明的函數(shù)從屬于那一個定義文件; 【建議3.2-3】宏定義和函數(shù)聲明分離,在兩個頭文件中定義,如果沒有類成員函數(shù),可以將類和結構的定義與函數(shù)聲明分離,也就是說一個頭文件專用于宏定義,一個頭文件專用于類和結構的定義,一個頭文件專用于函數(shù)聲明; 【建議3.2-4】在C+ 語法中,類的成員函數(shù)可以在聲明的同時被
20、定義,并且自動成為內聯(lián)函數(shù)。這雖然會帶來書寫上的方便,但卻造成了風格不一致,弊大于利。建議將成員函數(shù)的定義與聲明分開,不論該函數(shù)體有多么小。頭文件的結構如下:/文件信息聲明見示例3-1,此處省略。#ifndef_FILE_SYSTEM_H_/avoid referencing the file filesystem.h repeat#define_FILE_SYSTEM_H_#include /reference standard head file#include “myheader.h” /reference non-standard head filevoid Function1();/
21、global function declareclass CBox /class structure decalre;#endif示例3-2 C+/C頭文件的結構3.1.3 定義文件的結構定義文件有三部分內容:(1) 定義文件開頭處的文件信息聲明(參見示例3-1);(2) 對一些頭文件的引用;(3) 程序的實現(xiàn)體(包括數(shù)據(jù)和代碼)。假設定義文件的名稱為 filesystem.c,定義文件的結構參見示例3-3。/文件信息聲明見示例3-1,此處省略。#include “filesystem.h”/reference a head file/global function realizationvo
22、id Function1()/class member function realizationvoid CBox:Draw()示例3-3 C+/C定義文件的結構3.1.4 頭文件的作用早期的編程語言如Basic、Fortran沒有頭文件的概念,C+/C語言的初學者雖然會用使用頭文件,但常常不明其理。這里對頭文件的作用略作解釋:(1) 通過頭文件來調用庫功能。在很多場合,源代碼不便(或不準)向用戶公布,只要向用戶提供頭文件和二進制的庫即可。用戶只需要按照頭文件中的接口聲明來調用庫功能,而不必關心接口怎么實現(xiàn)的。編譯器會從庫中提取相應的代碼;(2) 頭文件能加強類型安全檢查。如果某個接口被實現(xiàn)或
23、被使用時,其方式與頭文件中的聲明不一致,編譯器就會指出錯誤,這一簡單的規(guī)則能大大減輕程序員調試、改錯的負擔。3.1.5 目錄結構如果一個軟件的頭文件數(shù)目比較多(如超過十個),通常應將頭文件和定義文件分別保存于不同的目錄,以便于維護。例如可將頭文件保存于include目錄,將定義文件保存于source目錄(可以是多級目錄)。如果某些頭文件是私有的,它不會被用戶的程序直接引用,則沒有必要公開其“聲明”。為了加強信息隱藏,這些私有的頭文件可以和定義文件存放于同一個目錄。3.2 命名規(guī)則比較著名的命名規(guī)則當推“匈牙利” 命名法,該命名規(guī)則的主要思想是“在變量和函數(shù)名中加入前綴以增進人們對程序的理解”。
24、例如所有的字符變量均以ch為前綴,若是指針變量則追加前綴p。如果一個變量由ppch開頭,則表明它是指向字符指針的指針?!靶傺览狈ㄗ畲蟮娜秉c是煩瑣,例如int i, j, k; float x, y, z;倘若采用“匈牙利”命名規(guī)則,則應當寫成int iI, iJ, ik; / 前綴 i表示int類型float fX, fY, fZ; / 前綴 f表示float類型如此煩瑣的程序會讓絕大多數(shù)程序員無法忍受??偟恼f來,沒有一種命名規(guī)則可以讓所有的程序員贊同,且命名規(guī)則對軟件產品而言并不是“成敗悠關”的事,而且在不同的平臺和不同的環(huán)境下編寫的程序所應遵循的規(guī)則也不盡相同,所以我們只是追求制定一種令
25、大多數(shù)項目成員滿意的命名規(guī)則,并在項目中貫徹實施。3.2.1 共性原則本節(jié)論述的共性規(guī)則是被大多數(shù)程序員采納的,我們應當在遵循這些共性規(guī)則的前提下,再擴充特定的規(guī)則,如3.2.2節(jié) 【規(guī)則3.2.1-1】標識符應當直觀且可以拼讀,可望文知意,不必進行“解碼”; 【規(guī)則3.2.1-2】標識符的長度應當符合“min-length & max-information”原則; 【規(guī)則3.2.1-3】命名規(guī)則盡量與所采用的操作系統(tǒng)或開發(fā)工具的風格保持一致; 【規(guī)則3.2.1-4】程序中不要出現(xiàn)僅靠大小寫區(qū)分的相似的標識符。 【規(guī)則3.2.1-5】程序中不要出現(xiàn)標識符完全相同的局部變量和全局變量,盡管兩者
26、的作用域不同而不會發(fā)生語法錯誤,但會使人誤解; 【規(guī)則3.2.1-6】變量的名字應當使用“名詞”或者“形容詞名詞”; 【規(guī)則3.2.1-7】全局函數(shù)的名字應當使用“動詞”或者“動詞名詞”(動賓詞組); 【規(guī)則3.2.1-8】用正確的反義詞組命名具有互斥意義的變量或相反動作的函數(shù)等; 【建議3.2.1-9】盡量避免名字中出現(xiàn)數(shù)字編號,如Value1,Value2等,除非邏輯上的確需要編號;注:3.2.1 標識符最好采用英文單詞或其組合,便于記憶和閱讀,切忌使用漢語拼音來命名,程序中的英文單詞一般不要太復雜,用詞應當準確,例如不要把CurrentValue寫成NowValue;3.2.2 標示符的
27、長度應當以最小的長度實現(xiàn)最多信息,一般來說,長名字能更好地表達含義,但并非長的變量名就一定要比短的變量名要好,此外單字符的名字也是有用的,常見的如i,j,k,m,n,x,y,z等,它們通??捎米骱瘮?shù)內的局部變量;3.2.3 不同的操作系統(tǒng)的程序設計風格是不一樣的,例如Windows應用程序的標識符通常采用“大小寫”混排的方式,如AddChild,而Unix應用程序的標識符通常采用“小寫加下劃線”的方式,如add_child,別把這兩類風格混在一起使用;3.2.2 Windows變量命名規(guī)則 【規(guī)則3.2.2-1】變量的命名規(guī)則要求采用“匈牙利法則”,即開頭字母用變量的類型,其余部分用變量的英文
28、意思或其英文意思的縮寫,盡量避免采用中文拼音,要求單詞的第一個字母大寫;即:變量名變量類型變量英文意思(或縮寫)變量類型請參見附表1變量類型表; 【規(guī)則3.2.2-2】類名和函數(shù)名用大寫字母開頭的單詞組合而成;對struct、union、class變量的命名要求定義的類型用大寫,結構采用S開頭,聯(lián)合體采用U開頭,類采用C開頭;例如:struct SPointintm_nX;intm_nY;union URecordLenBYTEm_byRecordNum;BYTEm_byRecordLen;class CNode/類成員變量或成員函數(shù); 【規(guī)則3.2.2-3】指針變量命名的基本原則為:一重指針
29、變量的基本原則為:變量名 “p”變量類型前綴命名對多重指針變量的基本原則為:二重指針:變量名“pp”變量類型前綴命名三重指針:變量名“ppp”變量類型前綴命名例如一個short*型的變量應該表示為pnStart; 【規(guī)則3.2.2-4】全局變量用g_開頭;例如一個全局的長型變量定義為g_lFileNum,即:變量名g_變量類型變量的英文意思(或縮寫); 【規(guī)則3.2.2-5】靜態(tài)變量采用s_開頭;例如一個靜態(tài)的指針變量定義為s_plPrevInst,即:變量名s_變量類型變量的英文意思(或縮寫); 【規(guī)則3.2.2-6】類成員變量采用m_開頭;例如一個長型成員變量定義為m_lCount,即:變
30、量名m_變量類型變量的英文意思(或縮寫); 【規(guī)則3.2.2-7】對const的變量要求在變量的命名規(guī)則前加入c_(若作為函數(shù)的輸入?yún)?shù),可以不加),即:變量名c_變量命名規(guī)則,例如:const char* c_szFileName; 【規(guī)則3.2.2-8】對枚舉類型(enum)中的變量,要求用枚舉變量或其縮寫做前綴,且用下劃線隔離變量名,所有枚舉類型都要用大寫,例如:enumEMDAYSEMDAYS_MONDAY;EMDAYS_TUESDAY;; 【規(guī)則3.2.2-9】對常量(包括錯誤的編碼)命名,要求常量名用大寫,常量名用英文意思表示其意思,用下劃線分割單詞,例如:#defineCM_78
31、16_OK0 x9000; 【規(guī)則3.2.2-10】為了防止某一軟件庫中的一些標識符和其它軟件庫中的沖突,可以為各種標識符加上能反映軟件性質的前綴。例如三維圖形標準OpenGL的所有庫函數(shù)均以gl開頭,所有常量(或宏定義)均以GL開頭。3.3 程序風格程序風格雖然不會影響程序的功能,但會影響程序的可讀性,追求清晰、美觀,是程序風格的重要構成因素。3.3.1 空行空行起著分隔程序段落的作用。空行得體(不過多也不過少)將使程序的布局更加清晰??招胁粫速M內存,雖然打印含有空行的程序是會多消耗一些紙張,但是值得。 【規(guī)則3.3.1-1】在每個類聲明之后、每個函數(shù)定義結束之后都要加空行。參見示例3.3
32、.1(a); 【規(guī)則3.3.1-2】在一個函數(shù)體內,邏揖上密切相關的語句之間不加空行,其它地方應加空行分隔。參見示例3.3.1(b);/ blank linevoid Function1() / blank linevoid Function2() / blank linevoid Function3() / blank linewhile (condition)statement1;/ blank lineif (condition) statement2;elsestatement3;/ blank linestatement4; 示例3.3.1(a) 函數(shù)之間的空行 示例3.3.1(b)
33、 函數(shù)內部的空行3.3.2 代碼行 【規(guī)則3.3.2-1】一行代碼只做一件事情,如只定義一個變量,或只寫一條語句,這樣的代碼容易閱讀,并且方便于寫注釋; 【規(guī)則3.3.2-2】if、for、while、do等語句自占一行,執(zhí)行語句不得緊跟其后,不論執(zhí)行語句有多少都要加,這樣可以防止書寫失誤; 【規(guī)則3.3.2-3】if、for、while、do等語句的“”要單獨占用一行; 【建議3.3.2-1】所有函數(shù)內的變量都在函數(shù)開始處定義; 【建議3.3.2-2】盡可能在定義變量的同時初始化該變量(就近原則),如果變量的引用處和其定義處相隔比較遠,變量的初始化很容易被忘記。如果引用了未被初始化的變量,可
34、能會導致程序錯誤,本建議可以減少隱患。示例3.3.2(a)為風格良好的代碼行,示例3.3.2(b)為風格不良的代碼行。int nWidth;/ widthint nHeight;/ heightint nDepth;/ depthint nWidth,nHight,nDepth;/width,height,depthx = a + b;y = c + d;z = e + f;X a + b; y = c + d; z = e + f;if (nWidth nHight) DoSomething();if (nWidth =”、“=”、“+”、“*”、“%”、“&”、“|”、“”這類操作符前后不
35、加空格; 【建議3.3.3-1】對于表達式比較長的for語句和if語句,為了緊湊起見可以適當?shù)厝サ粢恍┛崭?,如for (i=0; i10; i+)和if (a=b) & (c= 2000) / favorable styleif(year=2000) / ill styleif (a=b) & (c=b&c=d) / ill stylefor (i=0; i10; i+) / favorable stylefor(i=0;i10;i+) / ill stylefor (i = 0; I 10; i +) / favorable stylex = a b ? a : b; / favorable
36、 stylex=aFunction(); / Do not use b - Function();示例3.3.3 代碼行內的空格3.3.4 對齊 【規(guī)則3.3.4-1】程序的分界符和應獨占一行并且位于同一列,同時與引用它們的語句左對齊; 【規(guī)則3.3.4-2】 之內的代碼塊在右邊數(shù)格處左對齊; 【規(guī)則3.3.4.3】代碼的的對齊采用TAB鍵而不采用空格鍵對齊,一般TAB鍵設置為向后空4個空格。示例3.3.4(a)為風格良好的對齊,示例3.3.4(b)為風格不良的對齊。void Function(int x) / program codevoid Function(int x) / progra
37、m codeif (condition) / program codeelse / program codeif (condition) / program codeelse / program codefor (initialization; condition; update) / program codefor (initialization; condition; update) / program codeWhile (condition) / program codewhile (condition) / program code如果出現(xiàn)嵌套的,則使用縮進對齊,如: 示例3.3.4
38、(a) 風格良好的對齊 示例3.3.4(b) 風格不良的對齊3.3.5 長行拆分 【規(guī)則3.3.5-1】代碼行最大長度宜控制在70至80個字符以內; 【規(guī)則3.3.5-2】長表達式要在低優(yōu)先級操作符處拆分成新行,操作符放在新行之首(以便突出操作符),拆分出的新行要進行適當?shù)目s進,使排版整齊,語句可讀。if (very_longer_variable1 = very_longer_variable12)& (very_longer_variable3 = very_longer_variable14)& (very_longer_variable5 0 )*pbTo + = *pbFrom +
39、;return pvTo;示例3.4.5 復制不重疊的內存塊assert不是一個倉促拼湊起來的宏。為了不在程序的Debug版本和Release版本引起差別,assert不應該產生任何副作用。所以assert不是函數(shù),而是宏。程序員可以把assert看成一個在任何系統(tǒng)狀態(tài)下都可以安全使用的無害測試手段。如果程序在assert處終止了,并不是說含有該assert的函數(shù)有錯誤,而是調用者出了差錯,assert可以幫助我們找到發(fā)生錯誤的原因。 【規(guī)則3.4.5-1】使用斷言捕捉不應該發(fā)生的非法情況,不要混淆非法情況與錯誤情況之間的區(qū)別,后者是必然存在的并且是一定要作出處理的; 【規(guī)則3.4.5-2】在
40、函數(shù)的入口處,使用斷言檢查參數(shù)的有效性(合法性); 【建議3.4.5-1】在編寫函數(shù)時,要進行反復的考查,并且自問:“我打算做哪些假定?”一旦確定了的假定,就要使用斷言對假定進行檢查; 【建議3.4.5-2】一般教科書都鼓勵程序員們進行防錯設計,但要記住這種編程風格可能會隱瞞錯誤。當進行防錯設計時,如果“不可能發(fā)生”的事情的確發(fā)生了,則要使用斷言進行報警。3.4.6 引用與指針的比較引用是C+中的概念,初學者容易把引用和指針混淆一起。一下程序中,n是m的一個引用(reference),m是被引用物(referent)。int m;int &n = m;n相當于m的別名(綽號),對n的任何操作就
41、是對m的操作。所以n既不是m的拷貝,也不是指向m的指針,其實n就是m它自己。引用的一些規(guī)則如下:(1) 引用被創(chuàng)建的同時必須被初始化(指針則可以在任何時候被初始化);(2) 不能有NULL引用,引用必須與合法的存儲單元關聯(lián)(指針則可以是NULL);(3) 一旦引用被初始化,就不能改變引用的關系(指針則可以隨時改變所指的對象)。以下示例程序中,k被初始化為i的引用。語句k = j并不能將k修改成為j的引用,只是把k的值改變成為6。由于k是i的引用,所以i的值也變成了6。int i = 5;int j = 6;int &k = i;k = j;/ k和i的值都變成了6;上面的程序看起來象在玩文字游
42、戲,沒有體現(xiàn)出引用的價值。引用的主要功能是傳遞函數(shù)的參數(shù)和返回值。C+語言中,函數(shù)的參數(shù)和返回值的傳遞方式有三種:值傳遞、指針傳遞和引用傳遞。以下是“值傳遞”的示例程序。由于Func1函數(shù)體內的x是外部變量n的一份拷貝,改變x的值不會影響n, 所以n的值仍然是0。void Func1(int x)x = x + 10;int n = 0;Func1(n);cout “n = ” n endl;/ n = 0以下是“指針傳遞”的示例程序。由于Func2函數(shù)體內的x是指向外部變量n的指針,改變該指針的內容將導致n的值改變,所以n的值成為10。void Func2(int *x)(* x) = (*
43、 x) + 10;int n = 0;Func2(&n);cout “n = ” n endl;/ n = 10以下是“引用傳遞”的示例程序。由于Func3函數(shù)體內的x是外部變量n的引用,x和n是同一個東西,改變x等于改變n,所以n的值成為10。void Func3(int &x)x = x + 10;int n = 0;Func3(n);cout “n = ” n endl;/ n = 10對比上述三個示例程序,會發(fā)現(xiàn)“引用傳遞”的性質象“指針傳遞”,而書寫方式象“值傳遞”。3.5 變量類型定義類 型規(guī) 則范 例bool(BOOL)用b開頭bIsParentbyte(BYTE)用by開頭by
44、Flagshort(SHORT)用n開頭nFileLenint(INT)用n開頭nStepCountlong(LONG)用l開頭lSizechar(CHAR)用ch開頭chCountunsigned short(WORD)用w開頭wLengthunsigned long(DWORD)用dw開頭dwBroadvoid(VOID)用v開頭vVariant用0結尾的字符串用sz開頭szFileNameLPCSTR(LPCTSTR)用str開頭strStringHANDLE(HINSTANCE)用h開頭hHandlestruct用blk開頭blkTemplateBYTE*用pb開頭pbValueWOR
45、D*用pw開頭pwValueLONG*用pl開頭plValue四、軟件測試規(guī)范為了確保軟件產品質量,使產品能夠順利交付和通過驗收,特編寫軟件測試規(guī)范,以作參考 測試的依據(jù)來源于系統(tǒng)需求說明書、詳細設計、技術協(xié)議等有關資料。開發(fā)人員按照需求說明書進行軟件開發(fā)和測試。 測試之前要明確每次測試的目的,必要時可以編寫測試計劃,必須明確采用的測試環(huán)境、工具和測試軟件;采用的測試用例、測試數(shù)據(jù)和預期的結果,以達到不放過一個小的bug。下面介紹幾種常用的方法,僅作參考,如果開發(fā)人員有好的測試方法,可以隨時添加該文檔的內容。4.1 單元測試項目開發(fā)實現(xiàn)過程中,每個程序單元(程序單元的劃分視具體開發(fā)工具而定,一
46、般定為函數(shù)或子程序級)編碼調試通過后,要及時進行單元測試。單元測試由使用白盒測試方法,根據(jù)程序單元的控制流程,爭取達到分支覆蓋。對于交互式運行的產品,不便于進行自動測試的,可以采用功能測試的方法進行。單元測試針對程序模塊,從程序的內部結構出發(fā)設計測試用例。多個模塊可以獨立進行單元測試。單元測試內容包括模塊接口測試、局部數(shù)據(jù)結構測試、路徑測試、錯誤處理測試等;單元測試組織原則一遍根據(jù)開發(fā)進度安排對已開發(fā)完成的單一模塊進行測試;單元測試停止標準:完成了所有規(guī)定單元的測試,單元測試中發(fā)現(xiàn)的bug已經(jīng)得到修改。4.2 系統(tǒng)測試在項目開發(fā)完成之后,應對整個系統(tǒng)軟件和硬件進行系統(tǒng)測試。對性能、可靠性、健壯性、壓力承受力等方面分別進行評價,以驗證系統(tǒng)是否滿足規(guī)定的需要。系統(tǒng)測試一般進行如下幾種情況的測試:正常情況非正常情況破壞性測試邊界情況非法情況強度測試性能測試兼容性測試用戶友好性測試界面設計規(guī)范測試:光標的初始位置字體是否統(tǒng)一字號是否符合規(guī)定標題顏色按鈕的名稱是
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
- 4. 未經(jīng)權益所有人同意不得將文件中的內容挪作商業(yè)或盈利用途。
- 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
- 6. 下載文件中如有侵權或不適當內容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 2025年中國速食連鎖業(yè)市場前景預測及投資規(guī)劃研究報告
- 2025年度生物制藥研發(fā)項目履約保證金協(xié)議書3篇
- 2025年中國高速公路機電系統(tǒng)行業(yè)市場發(fā)展監(jiān)測及投資前景展望報告
- 二零二五年農行個人小微企業(yè)貸款抵押合同范本
- 2025年中國美國青蛙養(yǎng)殖行業(yè)全景評估及投資規(guī)劃建議報告
- 2025年中國抗靜電氣泡布行業(yè)市場發(fā)展前景及發(fā)展趨勢與投資戰(zhàn)略研究報告
- 二零二五年度精密車床采購合同(含刀具壽命預測)4篇
- 個人承包木工工程合同(2024年版)
- 二零二四年度新能源汽車推廣合作增補合同下載3篇
- 2025年度蟲草產品包裝設計與制作合同4篇
- 2024年萍鄉(xiāng)衛(wèi)生職業(yè)學院單招職業(yè)技能測試題庫標準卷
- 2024年高考數(shù)學(理)試卷(全國甲卷)(空白卷)
- DB32-T 4444-2023 單位消防安全管理規(guī)范
- 臨床三基考試題庫(附答案)
- 合同簽訂執(zhí)行風險管控培訓
- 九宮數(shù)獨200題(附答案全)
- 人員密集場所消防安全管理培訓
- JCT587-2012 玻璃纖維纏繞增強熱固性樹脂耐腐蝕立式貯罐
- 典范英語2b課文電子書
- 員工信息登記表(標準版)
- 春節(jié)工地停工復工計劃安排( 共10篇)
評論
0/150
提交評論