1、 軟件開發流程規范V1.0德聯軟件有限責任公司編制人： 侯秀美 審核人： 2015 年 8 月 19 日 目錄目錄0一、概述2二、開發流程規范32.1 系統軟硬件開發環境32.2 系統架構（系統組成）52.3 系統功能模塊設計62.4 系統功能開發流程圖62.5 開發修改記錄7三、開發代碼規范83.1 文件結構83.1.1 文件信息聲明83.1.2 頭文件的結構103.1.3 定義文件的結構113.1.4 頭文件的作用123.1.5 目錄結構133.2 命名規則133.2.1 共性原則133.2.2 Windows變量命名規則143.3 程序風格163.3.1 空行173.3.2 代碼行183

2、.3.3 代碼行內的空格193.3.4 對齊203.3.5 長行拆分223.3.6 修飾符的位置233.3.7 注釋233.4 函數設計263.4.1 參數的規則263.4.2 返回值的規則273.4.3 函數內部實現的規則303.4.4 其它建議323.4.5 使用斷言323.4.6 引用與指針的比較333.5 變量類型定義35四、軟件測試規范364.1 單元測試364.2 系統測試374.6 業務測試384.7 驗收測試384.8 用戶現場測試38五、軟件版本管理394.1版本管理的必要性39一、概述本文制定煙臺開發區德聯軟件有限責任公司計算機軟件開發規范文檔。本規范的目的是使公司軟件開發

3、項目階段清晰、要求明確、任務具體、編寫的代碼規范，使之規范化、系統化和工程化，向公司內從事軟件開發的工程師和管理人員提出一系列規范和要求，從而有利于開發過程的控制和管理，提高所開發軟件系統的質量，縮短開發時間，減少開發和維護費用，以保證項目高質量、順利進行。本規范包含：開發流程規范和開發代碼規范等，開發流程規范需要技術開發人員編寫相關內容，希望每個技術人員形成習慣，如有新的內容更新會及時通知大家，如有好的規范要求也可通知編制人員及時更新。本規范為煙臺開發區德聯軟件有限責任公司內部材料，嚴禁其他商業應用。二、開發流程規范接受開發任務，詳細閱讀軟件技術規范或技術文檔，如對技術文檔有疑義或者不清楚的

4、地方及時與項目總工或用戶溝通，根據文檔和溝通內容編寫項目開發計劃，必須包括但不限于系統軟硬件開發環境、系統架構、系統功能模塊設計、系統功能開發流程圖、開發修改記錄。2.1 系統軟硬件開發環境開發環境的搭建，最好形成文檔，便于以后同樣工作的使用。開發人員要明確系統開發擬采用的數據庫、操作系統、開發語言、開發工具、服務器等（具體到版本）。明確整個系統開發工作流程，至少應該包括以下流程。2.2 系統架構（系統組成）確定系統整體體系架構，各層次之間的數據流的連接，確定軟件服務器的硬件配置及用戶硬件資源配置， 確定與用戶軟件平臺的統一協調。 開發人員在繪制架構圖時給出基本框架，能反映出基本意義即可，可以

5、直接用文字代替例子中的圖片。圖1 系統邏輯架構圖舉例圖2 物理架構圖舉例2.3 系統功能模塊設計給出系統的主要功能模塊，每個模塊所包含的功能。圖3 圖書管理系統模塊規劃圖舉例2.4 系統功能開發流程圖給出系統主要功能的業務流程圖。圖4 系統功能業務流程圖舉例2.5 開發修改記錄1. 開發代碼做好備份（可以在完成一個重大功能之后，或者按時間周期性進行備份），以免由于不可抗力導致代碼不可修復。2.在每次重大修改之后要做好記錄（改動的具體細節），修改前的版本要及時備份，可以方面隨時還原系統。修改日期修改內容是否備份備注三、開發代碼規范在研究項目團隊協作開發的情況下（這里的團隊協作也適合于應用項目的開

6、發），編程時應該強調的一個重要方面是程序的易讀性，在保證軟件速度等性能指標能滿足用戶需求的情況下，能讓其他程序員容易讀懂你所編寫的程序。若研究項目小組的所有開發人員都遵循統一的、鮮明的一套編程風格，可以讓協作者、后繼者和自己一目了然，在很短的時間內看清楚程序結構，理解設計的思路，大大提高代碼的可讀性、可重用性、程序健壯性、可移植性、可維護性。制定本編程規范的目的是為了提高軟件開發效率及所開發軟件的可維護性，提高軟件的質量。本規范由程序風格、命名規范、注釋規范、程序健壯性、可移植性、錯誤處理以及軟件的模塊化規范等部分組成。此規范以C/C+程序設計討論。3.1 文件結構每個C+/C程序通常分為兩個

7、文件。一個文件用于保存程序的聲明（declaration），稱為頭文件。另一個文件用于保存程序的實現（implementation），稱為定義（definition）文件。C+/C程序的頭文件以“.h”為后綴，C程序的定義文件以“.c”為后綴，C+程序的定義文件通常以“.cpp”為后綴（也有一些系統以“.cc”或“.cxx”為后綴）。3.1.1 文件信息聲明文件信息聲明位于頭文件和定義文件的開頭（參見示例3-1），主要內容有：（1）       版權信息；（2）      

8、文件名稱，項目代碼，摘要，參考文獻；（3）       當前版本號，作者/修改者，完成日期；（4）       版本歷史信息；（5）       主要函數描述。 / Copyright (c) 2015, DeLianSoftCompany YanTai/ All rights reserved./ Filename ：filename.h/ Project Code ：The project code a

9、bout this file/ Abstract ：Describe the content of this file summarily/ Reference ：./ Version ：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 f

10、unctions ：/Function 1 Return code Function name(Parameter Explain)/Function 2 Return code Function name(Parameter Explain)/./Function n Return code Function name(Parameter Explain)/示例3-1 文件信息聲明       【規則3.1-1】文件信息聲明以兩行斜杠開始，以兩行斜杠結束，每一行都以兩個斜杠開始；    

11、60;  【規則3.1-2】文件信息聲明包含五個部分，各部分之間以一空行間隔；        【規則3.1-3】在主要函數部分描述了文件所包含的主要函數的聲明信息，如果是頭文件，這一部分是可以省略的。3.1.2 頭文件的結構頭文件由三部分內容組成： (1)    頭文件開頭處的文件信息聲明(參見示例3-1)；(2)    預處理塊；(3)    函數和類結構聲明等。假設頭文件名稱為 filesystem.h，頭文件的結構參見示

12、例3-2。       【規則3.2-1】為了防止頭文件被重復引用，應當用ifndef/define/endif結構產生預處理塊；“#ifndef”或者“#define”后以TAB鍵代替SPACE鍵做空格；如果頭文件名稱是由多個單詞組成，則各單詞間以下劃線“_”連接，例如有頭文件名稱為“filesystem.h”，則定義如下：“#ifndef_FILE_SYSTEM_H_”；       【規則3.2-2】用 #include< filename.h> 格式來引用

13、標準庫的頭文件(編譯器將從標準庫目錄開始搜索)；       【規則3.2-3】用 #include “filename.h” 格式來引用非標準庫的頭文件(編譯器將從用戶的工作目錄開始搜索)；       【建議3.2-1】頭文件中只存放“聲明”而不存放“定義”；       【建議3.2-1】頭文件中應包含所有定義文件所定義的函數聲明，如果一個頭文件對應多個定義文件，則不同定義文件內實現的函數要分開聲明，并作注釋以

14、解釋所聲明的函數從屬于那一個定義文件；       【建議3.2-3】宏定義和函數聲明分離，在兩個頭文件中定義，如果沒有類成員函數，可以將類和結構的定義與函數聲明分離，也就是說一個頭文件專用于宏定義，一個頭文件專用于類和結構的定義，一個頭文件專用于函數聲明；       【建議3.2-4】在C+ 語法中，類的成員函數可以在聲明的同時被定義，并且自動成為內聯函數。這雖然會帶來書寫上的方便，但卻造成了風格不一致，弊大于利。建議將成員函數的定義與聲明分開，不論該函數體有多么小。頭文

15、件的結構如下：/文件信息聲明見示例3-1，此處省略。 #ifndef_FILE_SYSTEM_H_/avoid referencing the file filesystem.h repeat#define_FILE_SYSTEM_H_#include <math.h>/reference standard head file#include “myheader.h” /reference non-standard head filevoid Function1();/global function declareclass CBox /class structure d

16、ecalre;#endif示例3-2 C+/C頭文件的結構 3.1.3 定義文件的結構定義文件有三部分內容：(1)    定義文件開頭處的文件信息聲明(參見示例3-1)；(2)    對一些頭文件的引用；(3)    程序的實現體（包括數據和代碼）。假設定義文件的名稱為 filesystem.c，定義文件的結構參見示例3-3。/文件信息聲明見示例3-1，此處省略。 #include “filesystem.h”/reference a head file/global function

17、 realizationvoid Function1() /class member function realizationvoid CBox:Draw()示例3-3 C+/C定義文件的結構3.1.4 頭文件的作用早期的編程語言如Basic、Fortran沒有頭文件的概念，C+/C語言的初學者雖然會用使用頭文件，但常常不明其理。這里對頭文件的作用略作解釋：（1） 通過頭文件來調用庫功能。在很多場合，源代碼不便（或不準）向用戶公布，只要向用戶提供頭文件和二進制的庫即可。用戶只需要按照頭文件中的接口聲明來調用庫功能，而不必關心接口怎么實現的。編譯器會從庫中提取相應的代碼；（2） 頭文件

18、能加強類型安全檢查。如果某個接口被實現或被使用時，其方式與頭文件中的聲明不一致，編譯器就會指出錯誤，這一簡單的規則能大大減輕程序員調試、改錯的負擔。3.1.5 目錄結構如果一個軟件的頭文件數目比較多（如超過十個），通常應將頭文件和定義文件分別保存于不同的目錄，以便于維護。例如可將頭文件保存于include目錄，將定義文件保存于source目錄（可以是多級目錄）。如果某些頭文件是私有的，它不會被用戶的程序直接引用，則沒有必要公開其“聲明”。為了加強信息隱藏，這些私有的頭文件可以和定義文件存放于同一個目錄。3.2 命名規則比較著名的命名規則當推“匈牙利” 命名法，該命名規則的主要思想是“在變量和函

19、數名中加入前綴以增進人們對程序的理解”。例如所有的字符變量均以ch為前綴，若是指針變量則追加前綴p。如果一個變量由ppch開頭，則表明它是指向字符指針的指針。“匈牙利”法最大的缺點是煩瑣，例如int i, j, k; float x, y, z;倘若采用“匈牙利”命名規則，則應當寫成int iI, iJ, ik; / 前綴 i表示int類型float fX, fY, fZ; / 前綴 f表示float類型如此煩瑣的程序會讓絕大多數程序員無法忍受。總的說來，沒有一種命名規則可以讓所有的程序員贊同，且命名規則對軟件產品而言并不是“成敗悠關”的事，而且在不同的平臺和不同的環境下編寫的程序所應遵循的規

20、則也不盡相同，所以我們只是追求制定一種令大多數項目成員滿意的命名規則，并在項目中貫徹實施。3.2.1 共性原則本節論述的共性規則是被大多數程序員采納的，我們應當在遵循這些共性規則的前提下，再擴充特定的規則，如3.2.2節       【規則3.2.1-1】標識符應當直觀且可以拼讀，可望文知意，不必進行“解碼”；       【規則3.2.1-2】標識符的長度應當符合“min-length && max-information”原則；  &#

21、160;    【規則3.2.1-3】命名規則盡量與所采用的操作系統或開發工具的風格保持一致；       【規則3.2.1-4】程序中不要出現僅靠大小寫區分的相似的標識符。       【規則3.2.1-5】程序中不要出現標識符完全相同的局部變量和全局變量，盡管兩者的作用域不同而不會發生語法錯誤，但會使人誤解；       【規則3.2.1-6】變量的名字應當使用“名詞”或者“形容詞名

22、詞”；       【規則3.2.1-7】全局函數的名字應當使用“動詞”或者“動詞名詞”(動賓詞組)；       【規則3.2.1-8】用正確的反義詞組命名具有互斥意義的變量或相反動作的函數等；       【建議3.2.1-9】盡量避免名字中出現數字編號，如Value1,Value2等，除非邏輯上的確需要編號；注：3.2.1       

23、60;      標識符最好采用英文單詞或其組合，便于記憶和閱讀，切忌使用漢語拼音來命名，程序中的英文單詞一般不要太復雜，用詞應當準確，例如不要把CurrentValue寫成NowValue；3.2.2              標示符的長度應當以最小的長度實現最多信息，一般來說，長名字能更好地表達含義，但并非長的變量名就一定要比短的變量名要好，此外單字符的名字也是有用的，常見的如i,j,k,m,n,x,y,z等，它

24、們通常可用作函數內的局部變量；3.2.3              不同的操作系統的程序設計風格是不一樣的，例如Windows應用程序的標識符通常采用“大小寫”混排的方式，如AddChild，而Unix應用程序的標識符通常采用“小寫加下劃線”的方式，如add_child，別把這兩類風格混在一起使用；3.2.2 Windows變量命名規則       【規則3.2.2-1】變量的命名規則要求采用“匈牙利法則”

25、，即開頭字母用變量的類型，其余部分用變量的英文意思或其英文意思的縮寫，盡量避免采用中文拼音，要求單詞的第一個字母大寫；即：變量名變量類型變量英文意思(或縮寫)變量類型請參見附表1變量類型表；       【規則3.2.2-2】類名和函數名用大寫字母開頭的單詞組合而成；對struct、union、class變量的命名要求定義的類型用大寫，結構采用S開頭，聯合體采用U開頭，類采用C開頭；例如：struct SPointintm_nX;intm_nY;union URecordLenBYTEm_byRecordNum;BYTEm_byRec

26、ordLen;class CNode/類成員變量或成員函數;     【規則3.2.2-3】指針變量命名的基本原則為：一重指針變量的基本原則為：變量名 “p”變量類型前綴命名對多重指針變量的基本原則為：二重指針：變量名“pp”變量類型前綴命名三重指針：變量名“ppp”變量類型前綴命名.例如一個short*型的變量應該表示為pnStart；     【規則3.2.2-4】全局變量用g_開頭；例如一個全局的長型變量定義為g_lFileNum，即：變量名g_變量類型變量的英文意思(或縮寫)；  

27、60;  【規則3.2.2-5】靜態變量采用s_開頭；例如一個靜態的指針變量定義為s_plPrevInst，即：變量名s_變量類型變量的英文意思(或縮寫)；     【規則3.2.2-6】類成員變量采用m_開頭；例如一個長型成員變量定義為m_lCount，即：變量名m_變量類型變量的英文意思(或縮寫)；       【規則3.2.2-7】對const的變量要求在變量的命名規則前加入c_(若作為函數的輸入參數，可以不加)，即：變量名c_變量命名規則，例如：const char* c_sz

28、FileName；       【規則3.2.2-8】對枚舉類型(enum)中的變量，要求用枚舉變量或其縮寫做前綴，且用下劃線隔離變量名，所有枚舉類型都要用大寫，例如：enumEMDAYSEMDAYS_MONDAY;EMDAYS_TUESDAY;.；       【規則3.2.2-9】對常量(包括錯誤的編碼)命名，要求常量名用大寫，常量名用英文意思表示其意思，用下劃線分割單詞，例如：#defineCM_7816_OK0x9000；    

29、;   【規則3.2.2-10】為了防止某一軟件庫中的一些標識符和其它軟件庫中的沖突，可以為各種標識符加上能反映軟件性質的前綴。例如三維圖形標準OpenGL的所有庫函數均以gl開頭，所有常量（或宏定義）均以GL開頭。3.3 程序風格程序風格雖然不會影響程序的功能，但會影響程序的可讀性，追求清晰、美觀，是程序風格的重要構成因素。3.3.1 空行空行起著分隔程序段落的作用。空行得體（不過多也不過少）將使程序的布局更加清晰。空行不會浪費內存，雖然打印含有空行的程序是會多消耗一些紙張，但是值得。       【規則3.3.

30、1-1】在每個類聲明之后、每個函數定義結束之后都要加空行。參見示例3.3.1(a)；       【規則3.3.1-2】在一個函數體內，邏揖上密切相關的語句之間不加空行，其它地方應加空行分隔。參見示例3.3.1(b)； / blank linevoid Function1() / blank linevoid Function2() / blank linevoid Function3()  / blank linewhile (condition)statement1;/ blank lineif (condit

31、ion) statement2;elsestatement3;/ blank linestatement4; 示例3.3.1(a) 函數之間的空行 示例3.3.1(b) 函數內部的空行 3.3.2 代碼行       【規則3.3.2-1】一行代碼只做一件事情，如只定義一個變量，或只寫一條語句,這樣的代碼容易閱讀，并且方便于寫注釋；       【規則3.3.2-2】if、for、while、do等語句自占一行，執行語句不得緊跟其后，不論執行語句有多少都要加，這樣可

32、以防止書寫失誤；       【規則3.3.2-3】if、for、while、do等語句的“”要單獨占用一行；       【建議3.3.2-1】所有函數內的變量都在函數開始處定義；       【建議3.3.2-2】盡可能在定義變量的同時初始化該變量(就近原則)，如果變量的引用處和其定義處相隔比較遠，變量的初始化很容易被忘記。如果引用了未被初始化的變量，可能會導致程序錯誤，本建議可以減少隱患。示例3.3.2(a)為

33、風格良好的代碼行，示例3.3.2(b)為風格不良的代碼行。  int nWidth;/ widthint nHeight;/ heightint nDepth;/ depth int nWidth,nHight,nDepth;/width,height,depth x = a + b;y = c + d;z = e + f;X a + b; y = c + d; z = e + f; if (nWidth < nHight) DoSomething();if (nWidth < nHight) DoSomething();for (

34、initialization; condition; update)DoSomething();/ blank lineOther(); for (initialization; condition; update) DoSomething();Other();  示例3.3.2(a) 風格良好的代碼行 示例3.3.2(b) 風格不良的代碼行3.3.3 代碼行內的空格       【規則3.3.3-1】關鍵字之后要留空格，象const、virtual、inline、case 等關鍵字之后至少要留一個空格，

35、否則無法辨析關鍵字，象if、for、while等關鍵字之后應留一個空格再跟左括號（，以突出關鍵字；       【規則3.3.3-2】函數名之后不要留空格，緊跟左括號（，以與關鍵字區別；       【規則3.3.3-3】（向后緊跟，）、，、;向前緊跟，緊跟處不留空格；       【規則3.3.3-4】，之后要留空格，如Function(x, y, z)，如果;不是一行的結束符號，其后要留空格，如for (init

36、ialization; condition; update)；       【規則3.3.3-5】賦值操作符、比較操作符、算術操作符、邏輯操作符、位域操作符，如“=”、“+=” “>=”、“<=”、“+”、“*”、“%”、“&&”、“|”、“<<”,“”等二元操作符的前后應當加空格；       【規則3.3.3-6】一元操作符如“!”、“”、“+”、“-”、“&”（地址運算符）等前后不加空格；   

37、;    【規則3.3.3-7】象“”、“.”、“->”這類操作符前后不加空格；       【建議3.3.3-1】對于表達式比較長的for語句和if語句，為了緊湊起見可以適當地去掉一些空格，如for (i=0; i<10; i+)和if (a<=b) && (c<=d) void Func1(int x, int y, int z); / favorable stylevoid Func1 (int x,int y,int z); / ill style

38、if (year >= 2000) / favorable styleif(year>=2000) / ill styleif (a>=b) && (c<=d) / favorable styleif(a>=b&&c<=d) / ill stylefor (i=0; i<10; i+) / favorable stylefor(i=0;i<10;i+) / ill stylefor (i = 0; I < 10; i +) / favorable stylex = a < b ? a : b; / fa

39、vorable stylex=a<b?a:b; / ill styleint *x = &y; / favorable style int * x = & y; / ill style array5 = 0; / Do not use array 5 = 0;a.Function(); / Do not use a . Function();b->Function(); / Do not use b -> Function(); 示例3.3.3 代碼行內的空格 3.3.4 對齊     &#

40、160; 【規則3.3.4-1】程序的分界符和應獨占一行并且位于同一列，同時與引用它們的語句左對齊；       【規則3.3.4-2】 之內的代碼塊在右邊數格處左對齊；       【規則3.3.4.3】代碼的的對齊采用TAB鍵而不采用空格鍵對齊，一般TAB鍵設置為向后空4個空格。 示例3.3.4(a)為風格良好的對齊，示例3.3.4(b)為風格不良的對齊。  void Function(int x) / program code v

41、oid Function(int x) / program code if (condition) / program codeelse / program codeif (condition) / program codeelse / program codefor (initialization; condition; update) / program codefor (initialization; condition; update) / program codeWhile (condition) / program codewhile (condition) / prog

42、ram code如果出現嵌套的，則使用縮進對齊，如：  示例3.3.4(a) 風格良好的對齊 示例3.3.4(b) 風格不良的對齊3.3.5 長行拆分       【規則3.3.5-1】代碼行最大長度宜控制在70至80個字符以內；       【規則3.3.5-2】長表達式要在低優先級操作符處拆分成新行，操作符放在新行之首（以便突出操作符），拆分出的新行要進行適當的縮進，使排版整齊，語句可讀。 if (very_longer_variable1 >=

43、 very_longer_variable12)&& (very_longer_variable3 <= very_longer_variable14)&& (very_longer_variable5 <= very_longer_variable16) DoSomething();virtual CMatrix CMultiplyMatrix (CMatrix leftMatrix, CMatrix rightMatrix); for (very_longer_initialization; very_longer_condition;

44、 very_longer_update)DoSomething();示例3.3.5 長行的拆分3.3.6 修飾符的位置修飾符 * 和 應該靠近數據類型還是該靠近變量名，是個有爭議的活題，若將修飾符 * 靠近數據類型，例如：int* x; 從語義上講此寫法比較直觀，即x是int 類型的指針，上述寫法的弊端是容易引起誤解，例如：int* x, y; 此處y容易被誤解為指針變量。雖然將x和y分行定義可以避免誤解，但并不是人人都愿意這樣做。       【規則3.3.6-1】應當將修飾符 * 和 緊靠變量名；3.3.7 注釋C語言的注釋符為“

45、/*/”。C+語言中，程序塊的注釋常采用“/*/”，行注釋一般采用“/”。注釋通常用于：（1）版本、版權聲明；（2）函數接口說明；（3）重要的代碼行或段落提示。雖然注釋有助于理解代碼，但注意不可過多地使用注釋。參見示例3.3.7。        【規則3.3.7-1】注釋是對代碼的“提示”，而不是文檔，程序中的注釋不可喧賓奪主，注釋太多了會讓人眼花繚亂，注釋的花樣要少；       【規則3.3.7-2】如果代碼本來就是清楚的，則不必加注釋；例如 i+; / i 加

46、 1，多余的注釋       【規則3.3.7-3】邊寫代碼邊注釋，修改代碼同時修改相應的注釋，以保證注釋與代碼的一致性，不再有用的注釋要刪除；       【規則3.3.7-4】注釋應當準確、易懂，防止注釋有二義性，錯誤的注釋不但無益反而有害；       【規則3.3.7-5】盡量避免在注釋中使用縮寫，特別是不常用縮寫；       【規則3.3.7-6

47、】注釋的位置應與被描述的代碼相鄰，可以放在代碼的上方或右方，不可放在下方；       【規則3.3.7-8】當代碼比較長，特別是有多重嵌套時，應當在一些段落的結束處加注釋，便于閱讀；       【建議3.3.7-9】對于多行代碼的注釋，盡量不采用“/*.*/”，而采用多行“/”注釋，這樣雖然麻煩，但是在做屏蔽調試時不用查找配對的“/*.*/”。 / Function capacity：/ Parameter declare：/ Return value ：/vo

48、id Function(float x, float y, float z)  if () while () / end of while / end of if示例3.3.7 程序的注釋3.7.1 文件頭的注釋文件頭的注釋請參見3.1，文件頭的注釋是以兩行斜杠開始，以兩行斜杠結束(以區別于函數的注釋)。3.7.2 函數頭的注釋一般說來每個函數都應該做詳細的注釋，函數頭的注釋是以一行斜杠開始，以一行斜杠結束，注釋的內容包括“功能”，“參數”，“返回值”，“設計思想”，“調用函數”，“日期”，“修改記錄”等幾個方面，函數頭的注釋格式如下：/ Function capacity ：Des

49、cribe the function capacity/ Parameter declare ：/ parameter 1： Describe the function of parameter ( input/output parameter )/ parameter 2： Describe the function of parameter ( input/output parameter )/./ Return value ： Describe the possible return value/ Designed idea ： Describe designed idea about

50、the function/ Author ：/ Creation date ： Creation date(YY-MM-DD)/ Transferred function：List the sub-function in the function/ Modification record：/ (一)Mender 1：Modified date：modified content/3.4 函數設計函數是C+/C程序的基本功能單元，其重要性不言而喻。函數設計的細微缺點很容易導致該函數被錯用，所以光使函數的功能正確是不夠的。本章重點論述函數的接口設計和內部實現的一些規則。函數接口的兩個要素是參數和返回

51、值。C語言中，函數的參數和返回值的傳遞方式有兩種：值傳遞（pass by value）和指針傳遞（pass by pointer）。C+ 語言中多了引用傳遞（pass by reference）。由于引用傳遞的性質象指針傳遞，而使用方式卻象值傳遞，初學者常常迷惑不解，容易引起混亂，請先閱讀3.4.6節“引用與指針的比較”。3.4.1 參數的規則       【規則3.4.1-1】參數的書寫要完整，不要貪圖省事只寫參數的類型而省略參數名字，如果函數沒有參數，則用void填充；例如：void SetValue(int nWidth, in

52、t nHeight);/ 良好的風格void SetValue(int, int);/ 不良的風格float GetValue(void);/ 良好的風格float GetValue();/ 不良的風格       【規則3.4.1-2】參數命名要恰當，順序要合理；例如編寫字符串拷貝函數StringCopy，它有兩個參數，如果把參數名字起為str1和str2，例如：void StringCopy(char *str1, char *str2);那么我們很難搞清楚究竟是把str1拷貝到str2中，還是剛好倒過來，可以把參數名字起得更有意

53、義，如叫strSource和strDestination。這樣從名字上就可以看出應該把strSource拷貝到strDestination。還有一個問題，這兩個參數那一個該在前那一個該在后？參數的順序要遵循程序員的習慣。一般地，應將目的參數放在前面，源參數放在后面。如果將函數聲明為：void StringCopy(char *strSource, char *strDestination);別人在使用時可能會不假思索地寫成如下形式：char str20;StringCopy(str, “Hello World”);/ 參數順序顛倒     &#

54、160;  【規則3.4.1-3】如果參數是指針，且僅作輸入用，則應在類型前加const，以防止該指針在函數體內被意外修改。例如：void StringCopy(char *strDestination，const char *strSource);       【規則3.4.1-4】如果輸入參數以值傳遞的方式傳遞對象，則宜改用“const &”方式來傳遞，這樣可以省去臨時對象的構造和析構過程，從而提高效率；       【建議3.4.1-1】避免函數有太多

55、的參數，參數個數盡量控制在5個以內。如果參數太多，在使用時容易將參數類型或順序搞錯；       【建議3.4.1-2】盡量不要使用類型和數目不確定的參數；C標準庫函數printf是采用不確定參數的典型代表，其原型為：int printf(const chat *format, argument);這種風格的函數在編譯時喪失了嚴格的類型安全檢查。3.4.2 返回值的規則       【規則3.4.2-1】不要省略返回值的類型；C語言中，凡不加類型說明的函數，一律自動按整型處理

56、，這樣做不會有什么好處，卻容易被誤解為void類型；C+語言有很嚴格的類型安全檢查，不允許上述情況發生。由于C+程序可以調用C函數，為了避免混亂，規定任何C+/ C函數都必須有類型。如果函數沒有返回值，那么應聲明為void類型       【規則3.4.2-2】函數名字與返回值類型在語義上不可沖突；違反這條規則的典型代表是C標準庫函數getchar。例如：char c;c = getchar();if (c = EOF)按照getchar名字的意思，將變量c聲明為char類型是很自然的事情。但不幸的是getchar的確不是char類型

57、，而是int類型，其原型如下：int getchar(void);由于c是char類型，取值范圍是-128，127，如果宏EOF的值在char的取值范圍之外，那么if語句將總是失敗，這種“危險”人們一般哪里料得到！導致本例錯誤的責任并不在用戶，是函數getchar誤導了使用者       【規則3.4.2-3】不要將正常值和錯誤標志混在一起返回。正常值用輸出參數獲得，而錯誤標志用return語句返回；       【建議3.4.2-1】有時候函數原本不需要返回值，但為了增加靈

58、活性如支持鏈式表達，可以附加返回值；例如字符串拷貝函數strcpy的原型：char *strcpy(char *strDest，const char *strSrc);strcpy函數將strSrc拷貝至輸出參數strDest中，同時函數的返回值又是strDest。這樣做并非多此一舉，可以獲得如下靈活性：char str20;int nLength = strlen( strcpy(str, “Hello World”) );       【建議3.4.2-2】如果函數的返回值是一個對象，有些場合用“引用傳遞”替換“值傳遞”可以提高效

59、率。而有些場合只能用“值傳遞”而不能用“引用傳遞”，否則會出錯；對于建議3.4.2-2，如果函數的返回值是一個對象，有些場合用“引用傳遞”替換“值傳遞”可以提高效率，而有些場合只能用“值傳遞”而不能用“引用傳遞”，否則會出錯，例如：class String/ 賦值函數String& operate=(const String &other);/ 相加函數，如果沒有friend修飾則只許有一個右側參數friendString operate+( const String &s1, const String &s2); private:char *m_data; ;String的賦值函數operate = 的實現如下：String & String:operate=(const String &other)if (this =