編寫優(yōu)質(zhì)無錯代碼
一. 引言
八月上旬，深圳舉辦了一個討論會，主題是"編寫優(yōu)質(zhì)無錯代碼"。這個討論會吸引了深圳各大軟件公司，通信公司的程序員，系統(tǒng)分析員參加，并在討論會后紛紛表示，這種討論會很有實際價值，希望將這種形式的討論會繼續(xù)下去，形成一個論壇，以提高大家的編程水平和交換有價值的信息資料。
這個活動的發(fā)起是從網(wǎng)絡(luò)上開始的。我偶然看到了這個討論會的論題，發(fā)生了興趣。本來周末的我一般是很懶的，沒什么事情是不會出門的。而當(dāng)我看到這論題后，就給舉辦者發(fā)信表示愿意參加。于是，一個周六的下午，我就坐在了討論會的現(xiàn)場。參加完這個討論后，我覺得有必要把其中的精華部分寫下來，和網(wǎng)絡(luò)上的廣大程序員共享，于是就有了這篇文章。 二.主題：
編寫優(yōu)質(zhì)無錯的代碼---討論會主題。相信每個程序員都有這種希望，誰都不愿意自己寫出來的代碼在release之后出錯，需要不停的修改維護(hù)。但是，主持人提出了這樣一個問題："編寫優(yōu)質(zhì)無錯代碼是否必要？" 為什么呢？我稍微解釋一下。在項目的時間很緊張的時候，是按期完成任務(wù)重要，還是代碼的穩(wěn)定性，優(yōu)質(zhì)無錯重要呢？
主持人提出的四個具體問題是：
1、編寫優(yōu)質(zhì)無錯的代碼的代價是什么？
2、代碼的質(zhì)量重要還是編寫效率重要？
3、在壓力的情況下，你會犧牲質(zhì)量來提高效率么？
4、編寫優(yōu)質(zhì)無錯的代碼是否意味著效率的降低?
對于第一個問題，編寫優(yōu)質(zhì)無錯代碼的代價當(dāng)然是時間，不過隨著編程人員的經(jīng)驗逐漸豐富，所需要的時間也逐漸減少。
對于第二個問題，代碼的質(zhì)量比編寫效率重要。當(dāng)你花了1周時間寫出來的代碼需要你花一個月或者更長的時間去debug, 去修改錯誤，這種效率的損失是得不償失的。
對于第三個問題， 這需要看項目經(jīng)理或者產(chǎn)品經(jīng)理的態(tài)度和專業(yè)精神了。如果在一個專業(yè)的項目經(jīng)理或者產(chǎn)品經(jīng)理的指揮下，當(dāng)然是首先保證質(zhì)量其次提高效率。而對于某些項目經(jīng)理或者產(chǎn)品經(jīng)理來說，按時完成任務(wù)是最重要的，他們往往不在乎在軟件發(fā)布之后花比開發(fā)時間長得多的時間去修改程序，維護(hù)錯誤。因為，對于他們來說，首先是要完成任務(wù)，好給上級領(lǐng)導(dǎo)交差，至于后期維護(hù)，就是另外一個任務(wù)了，維護(hù)花的時間多，正說明了他這個項目的復(fù)雜性和難度。而對于開發(fā)人員來講，所希望的則正好相反。開發(fā)人員不喜歡花太多的時間在一個爛攤子上。所以，在討論會上，大家紛紛表示，應(yīng)該讓項目經(jīng)理或者產(chǎn)品經(jīng)理也來聽一聽這個討論會:-)。
對于第四個問題，當(dāng)然優(yōu)質(zhì)無錯代碼不是意味著效率的降低，而是正好相反，對提高效率有很好的促進(jìn)作用。一個版本發(fā)布之后，如果因為錯誤太多，開發(fā)人員不得不去花很多時間修改bug, 甚至要從系統(tǒng)的體系結(jié)構(gòu)方面去做大的改動，重新編寫部分代碼，這種效率的降低才是更大，更不能承受的。而且，花了太多的時間在老版本的維護(hù)上，必然影響到新版本的工程進(jìn)度，直接影響到整個產(chǎn)品線的質(zhì)量和進(jìn)度，嚴(yán)重的甚至?xí)У粽麄€產(chǎn)品。
對于這一個主題，我的回答是，在時間允許的范圍之內(nèi)，盡量提高代碼的質(zhì)量，不追求慢工出細(xì)活，不追求代碼的100%無錯，但是要保證99%以上的無錯。這樣，在時間的壓力下，在質(zhì)量要求的束縛下，就要求程序員有一個良好的習(xí)慣，和穩(wěn)健的編程風(fēng)格，以保證代碼的優(yōu)質(zhì)無錯。這就是第二個問題：什么是編寫優(yōu)質(zhì)無錯的代碼的核心思想？優(yōu)質(zhì)無錯是相對的，而不是絕對的。任何代碼，都不可能說是絕對無錯的，但是在絕大部分情況下，是穩(wěn)定的，強健的，優(yōu)質(zhì)的，無錯的。每次發(fā)布的時候，都會對上次的發(fā)布版本做若干修改，增強功能的同時，也要修改若干bug。
那么，核心思想就是:
怎樣才能自動地查出這個錯誤。
怎樣才能避免這個錯誤。
三.編寫優(yōu)質(zhì)無錯代碼的經(jīng)驗
在說了上面很多理論性的問題之后，來看一看具體問題。
先來看一看一個具體的題目：（我本人就是先在網(wǎng)上看了這個題目，才對這個討論會發(fā)生興趣的）
題目1:
作為開發(fā)團(tuán)隊的一員，你需要實現(xiàn)一些庫函數(shù)提供給其他人使用。假設(shè)你實
現(xiàn)的一個函數(shù)原型如下：
int DoSomeThing(char* pParam)
{
...
}
你們約定好參數(shù)pParam不能為NULL，但為了防止調(diào)用者錯誤傳遞NULL，你需要在你的函數(shù)里做判斷處理。
請問你會選擇那種方式，并說明原因？
(a) if (!pParam)
return 0;
(b) if (!pParam)
return ERROR_PARAM;
(c) if (!pParam)
pParam = "";
...
(d) if (!pParam)
throw EXCEPTION_ERROR_PARAM;
(e) if (!pParam)
MessageBox(...);
(f) assert(!pParam);
（附加說明一點，基于目前開發(fā)人員技術(shù)分布情況和參與討論會的人員的技術(shù)分布情況，這次所列舉的例子都是C/C++和Java方面的，不涉及到VB, PB,Delphi等語言。不過對于這些程序員，討論也是有借鑒作用的。）
關(guān)于這個問題，大概是所有的程序員都會遇到的。所以，在網(wǎng)上和討論會上，都發(fā)生了激烈的爭論和意見交換。我大概把主要的幾種觀點記錄了一下，列舉在下面：
1、選擇f的理由
因為非NULL是約定，所以可以確定是調(diào)用者的問題，f可以明確地指出這一點，防止錯誤擴散。
我的附加說明: 防止錯誤擴散的意思是，如果用其他方式，比如throwexception的方式，這個異常不一定會在調(diào)用此函數(shù)的上一層被捕捉到，可能會被繼續(xù)拋出直到最上一層或者直到在某一層被catch到，這樣的話，錯誤就會距離發(fā)生地點很遠(yuǎn)，擴散開來。
這一觀點，代表了一大部分的程序員的觀點。
2、反對用f
不贊成assert, assert更重要的作用是程序體里面的一個注釋, 在閱讀程序的時候起作用不能依賴他來檢測錯誤, 很大程度上assert容易使使用者依賴它本不應(yīng)該依賴的東西。這也代表了部分程序員的觀點，認(rèn)為assert是不可依賴的，而應(yīng)該依賴于錯誤檢測，比如返回值或者異常。
3、另外一種觀點
f和d都可取。如果沒有系統(tǒng)開銷的考慮，d則更好些。可以一舉兩得。如果沒人catch這個exception，其結(jié)果就跟f一樣，按bug處理，dump core留下一stack trace。如果有人catch，那就按運行錯誤處理......但是返回一特初值表示錯誤，只是將錯誤上交，掩耳盜鈴而已。最終總得有個人assert,messagebox,throw exception,perror+exit,或別得什么的。既然已經(jīng)是約定，就干脆付起責(zé)任。
4、一種反對d的理由
不可用d, 這就像你用人,卻不相信人一樣,偏要try,catch防范他。其實那個錯是自己造成的,如果看到異常就容易不檢討自己。
5、關(guān)于觀點3的支持意見
討論過程中，有人認(rèn)為assert檢查的是bug, 而異常是可以恢復(fù)的意外情況。所以，觀點3的支持者說：可恢復(fù)的意外是可以理解的，但可恢復(fù)的bug就沒什么意義了。既然已經(jīng)約定好了，你再違背，就屬于是bug而不是意外了(比如打不開文件什么的)。很多庫函數(shù)都不檢查指針的合法性(除了系統(tǒng)調(diào)用以外，因為總不能讓系統(tǒng)dump core吧)，也不檢查指針是否為NULL(因為如果層層都檢查，必定勞民傷財，干脆讓最上面調(diào)用的人在調(diào)用之外查)。
6、選擇d+f
選f+d, 好處如下：
a以最激烈的方式，充分暴露調(diào)用都的錯誤！能及時修改BUG
b便于調(diào)試,問題出現(xiàn)后，直接到事故現(xiàn)場。比120還快！
c對于realse版的代碼沒有任何副作用。
d以處理的代價來看 采用斷言也是編寫最小一種。
e它是多語種，多平臺所通用的方式， 如:C /C++ VB,Java1.4 在win ,unix
通吃, 便于移置!
如果在現(xiàn)實中，測試沒有能找到所有的BUG,那可能就要用異常來幫忙了！
當(dāng)然，我也提出了我的觀點, 我支持觀點6。理由如下：
assert只在debug標(biāo)志的時候有用，而在編譯release版本的時候不起作用。assert對于檢查硬編碼的錯誤，是非常有用的，能夠及時的查處編碼的錯誤。比如borland c++的類庫源代碼中就有很多這樣的assert。但是assert不是萬能的，因為有很多錯誤的發(fā)生不是完全在編譯時發(fā)生的，而是運行時的錯誤。在release后，assert是不可能依賴的。那么，我們就需要exception這一機制來檢測運行時錯誤，并相應(yīng)的做出處理。當(dāng)然，在異常檢測和處理過程中還有許多需要討論的問題，由于不是這一題目的范圍，我們沒有必要繼續(xù)討論得太多，但是，提出來希望大家注意：異常不是捕獲了就完成任務(wù)了，而要對于不同的情況，采取不同的處理辦法，千萬不能只是捕獲，而不做任何處理，那樣和不捕獲異常沒有任何別。 在題目剛剛提出的時候，選擇各種答案的人都有，所以，我有必要在這里把其他答案為什么不能選的理由說一下。 (a) if (!pParam)
return 0;
這是很多初級程序員常常采取的一種方式。返回值設(shè)為0。 因為函數(shù)的返回值往往是計算的結(jié)果，不贊成把錯誤標(biāo)志值和計算結(jié)果混在一起使用，容易造成使用者的誤會。當(dāng)然，在很多unix函數(shù)中，由于歷史原因，還存在很多這樣子的函數(shù)，所以需要指出，不要沿用這種方式。
(b) if (!pParam)
return ERROR_PARAM;
b比a稍微好一點點，返回了一個常量或者預(yù)定義的宏。 從返回值的字面上，調(diào)用者能知道發(fā)生了什么錯誤，但是，這也不是一種好的方法。
(c) if (!pParam)
pParam = "";
...
這是最不好的方式。直接給pParam賦予空字符串，然后繼續(xù)函數(shù)過程，這容易造成不可預(yù)料的后果，是程序不穩(wěn)定的根源。
(d) if (!pParam)
throw EXCEPTION_ERROR_PARAM;拋出異常，剛剛已經(jīng)討論過了，不再贅述。
(e) if (!pParam)
MessageBox(...);
這是一種比較可笑的方式，當(dāng)然也有不少人用。MessageBox是直接彈出一個對話框，告訴使用者，出錯了。但是并不做任何處理，程序繼續(xù)往下執(zhí)行，直到出錯崩潰。呵呵
(f) assert(!pParam);
斷言，剛剛已經(jīng)討論過了，不再贅述。
以上這個題目，引發(fā)了所有與會者的興趣，討論異常熱烈，最后，主持人也給出了自己的觀點:d+f。當(dāng)然這并不是標(biāo)準(zhǔn)答案，因為編程這一門課程本來就沒有什么標(biāo)準(zhǔn)答案，大家見仁見智，這個答案只是經(jīng)驗的積累。
主持人緊接著列出了"編寫優(yōu)質(zhì)無錯代碼的經(jīng)驗":
a.理想的編譯器和實際的編譯器
b.使用斷言
c.函數(shù)的界面設(shè)計
d.考慮風(fēng)險
e.態(tài)度的問題
以上是本節(jié)的主要內(nèi)容。斷言，剛剛的問題中已經(jīng)討論過了，來看看其他的內(nèi)容。
理想的編譯器和實際的編譯器:
題目二：
下面memcpy函數(shù)實現(xiàn)有什么問題：
Void *memcpy(void *pvTo,void *pvFrom,size_t size){
byte *pbTo=(byte *) pvTo;
byte *pbFrom=(byte *)pvFrom；
while(size -- >0)；
*pbTo++= *pbFrom++;
return pvTo;
}
呵呵，粗略一看，這函數(shù)還真找不出問題來。但是仔細(xì)看看，你就會發(fā)現(xiàn)while(size -- >0)；這里多了一個分號，導(dǎo)致下面的*pbTo++= *pbFrom++;不是在while循環(huán)中執(zhí)行多次，而是只執(zhí)行了一次。當(dāng)然這不是函數(shù)設(shè)計者的預(yù)期結(jié)果，而編譯器卻不會報告錯誤，因為while(size -- >0)；從語法上來講，并沒有錯誤。這就是理想的編譯器和實際的編譯器的區(qū)別所在。
那么，該怎么檢查這種錯誤呢？主持人提出了如下辦法：
while(size -- >0) NULL; 可以加入NULL來解決空語句. 這樣子，當(dāng)你需
要 while(size -- >0)
*pbTo++= *pbFrom++;
這種形式的時候，就不會發(fā)生錯誤了，只需要用眼睛看看，就能發(fā)現(xiàn)了。
兩點好處 1 無冗余代碼，2 使人更明白。減少風(fēng)險.
還有人會這么寫
if( (n=read(....)) == 1) ....
在這里，賦值符號=和判斷相等的符號==容易敲錯，而編譯器又檢查不出來，可能就會有如下錯誤：
If(ch = ‘ ’)...；這也是需要注意的問題。
理想的編譯器和實際的編譯器小結(jié)：
a.把屢次出錯的合法的C習(xí)慣用法看成程序中的錯誤
b.增強編譯器的警告級別
c.使用其它的工具來檢查代碼 如 Lint 等
d.進(jìn)行單元測試
e.消除程序錯誤的最好方法是盡可能早、盡可能容易地發(fā)現(xiàn)錯誤，要尋求費力最小的自動查錯的方法
f.努力減少程序員查錯所需的技巧
使用斷言
題目三
下面函數(shù)實現(xiàn)，哪一個好，為什么？
a.
char Uptolower(char ch){
if(ch >= ‘A’ && ch <= ‘Z’)
return ch+=‘a(chǎn)’-’A’;
return -1;
}
b.
char Uptolower(char ch){
assert(ch >= ‘A’ && ch <= ‘Z’)；
if(ch >= ‘A’ && ch <= ‘Z’)
return ch+=‘a(chǎn)’-’A’;
return ch;
}
c.
char Uptolower(char ch){
assert(ch >= ‘A’ && ch <= ‘Z’)；
return ch+(‘a(chǎn)’-’A’);
}
分析：
a.該函數(shù)檢查ch是否在A..Z之間，如果是，則返回相應(yīng)的小寫字符，如果
不是，則返回-1。
缺點在于：把錯誤標(biāo)志值和計算結(jié)果混在一起使用，容易造成使用者的誤會。
b.該函數(shù)使用了斷言，如果ch在A..Z之間則返回相應(yīng)的小寫字符，如果不是，斷言會起作用，程序發(fā)生錯誤并退出。而最后一個return ch;則是在release的時候，如果不是A..Z之間，則返回原來的字符。但是，從書寫效率上來說，這個函數(shù)稍微羅嗦了一點。因為它重復(fù)使用了斷言和if判斷。
c.該函數(shù)也使用了斷言，返回相應(yīng)大寫字母的小寫字母。
使用斷言的好處：
a.暴露了調(diào)用者的錯誤
b.便于調(diào)試
c.對代碼沒有代價
d.最少的處理代價
斷言使用舉例：
void memcpy(void * pvTo,void *pvFrom,size_t size){
void *pbTo= (byte *)pvTo;
void *pbFrom= (byte * pvFrom);
assert(pvTo !=NULL && pvFrom !=NULL);
assert(pbTo >= pbFrom +size' 'pbFrom >= pbTo+size);
…
}
使用斷言的規(guī)則：
a.要使用斷言對函數(shù)參數(shù)進(jìn)行確認(rèn)
b.要從程序中刪去無定義的特性或者在程序中使 用斷言來檢查出無定義特性的非法使用
c.不要浪費別人的時間-詳細(xì)說明不清楚的斷言
d.消除所做的隱式假定，或者利用檢查其正確性
e.在進(jìn)行防錯性程序設(shè)計時，不要隱瞞錯誤防錯性程序設(shè)計雖然被譽為有較好的編碼風(fēng)格，但它卻隱瞞了錯誤。要記住，我們正在談?wù)摰腻e誤決不應(yīng)該再發(fā)生，而對這些錯所進(jìn)行的安全處理
又編寫無錯代碼變得更加困難
f.要利用不同的算法對程序的結(jié)果進(jìn)行確認(rèn)
g.不要等待錯誤發(fā)生，要使用初始檢查程序
斷言小結(jié)：
a.要同時維護(hù)交付和調(diào)試兩個版本。封裝交付的版本，應(yīng)盡可能地使用調(diào)試版本進(jìn)行自動查錯。
b.斷言是進(jìn)行調(diào)試檢查的簡單方法。要使用斷言捕捉不應(yīng)該發(fā)生的非法情況。不要混淆非法情況與錯誤情況之間的區(qū)別，后者是在最終產(chǎn)品中必須處理的。
c.使用斷言對函數(shù)的參數(shù)進(jìn)行確認(rèn)，并且在程序員使用了無定義的特性時向程序員報警。涵數(shù)定義得越嚴(yán)格，確認(rèn)其參數(shù)就越容易。
d.防錯性程序設(shè)計會隱瞞錯誤。在進(jìn)行防錯編碼時，如果”不可能發(fā)生”的情況確實發(fā)生了，要使用斷言進(jìn)行報警。
寫到這里，我們初步探討了編寫優(yōu)質(zhì)無錯代碼的必要性，原則，和相關(guān)經(jīng)驗。留幾個練習(xí)題目，大家也參與一下討論吧。
練習(xí)題目1:
下面的memset函數(shù)實現(xiàn)有什么問題？
void *memset(void *pv, byte b, size_t size)
{
byte *pb = (byte *)pv;
unsigned long l;
size_t sizeSize;
l = (b << 8) | b; /* 用4個字節(jié)拼成一個long */
l = (l << 16) | l;
pb = (byte *)longfill((long *)pb, l, size/4);
size = size % 4;
while (size-- > 0)
*pb++ = b;
return (pv);
}
練習(xí)題目2:
下面的代碼用memset將三個局部變量置為0，請問可能會有什么問題？
void DoSomeThing(...)
{
int i;
int j;
int k;
memset(&k, 0, 3*sizeof(int)); // 將i,j,k置為0
...
}
練習(xí)題目3:
定義結(jié)構(gòu)如下：
typedef struct
{
char c1;
char c2;
int n;
} stru;
請問sizeof(stru)等于多少？并說明理由。
練習(xí)題目4:
下面是C語言中兩種if語句判斷方式。請問哪種寫法更好？為什么？
int n;
if (n == 10) // 第一種判斷方式
if (10 == n) // 第二種判斷方式
練習(xí)題目5:
下面的代碼有什么問題？
void DoSomeThing(...)
{
char* p;
...
p = malloc(1024); // 分配1K的空間
if (NULL == p)
return;
...
p = realloc(p, 2048); // 空間不夠，重新分配到2K
if (NULL == p)
return;
...
}
練習(xí)題目6:
下面的代碼有什么問題？
char *DoSomeThing(...)
{
char str[16];
...
return str;
}
練習(xí)題目7:
下面的代碼有什么問題？
char *_strdup( const char *strSource )
{
static char str[MAX_STR_LEN];
strcpy(str, strSource);
return str;
}
練習(xí)題目8:
下面的代碼有什么問題？并請給出正確的寫法。
try{
FILE* fp = fopen("c:1.dat");
if (NULL != fp)
{
...
}
fclose(fp);
}
except(EXCEPTION_EXECUTE_HANDLER){
}
我敲字敲累了，告一段落吧。不過，討論會并不止討論了這些內(nèi)容，還有很多內(nèi)容我沒有寫完，比如，函數(shù)的界面, 編寫代碼的風(fēng)險, 編程的態(tài)度等等問題。作為補充，我把討論會的幻燈片修改成了文本版本，作為另外一篇文章放在這里，以便對這個話題感興趣的網(wǎng)友們參考。
