魔數
程序里許多上下文中經常出現的0。雖然編譯系統會
把它轉換為適當類型，但是，如果我們把每個0的類型寫得更明確更清楚，對讀程序的人理解
其作用是很有幫助的。例如，用(void *) 0或NULL表示C里的空指針值，用‘\ 0’而不是0表示
字符串結尾的空字節。也就是說，不要寫：
str = 0;
name[i]=0;
x = 0;
應該寫成：
str = NULL;
name[il = ' \ 0 ' ;
x = 0.0;
我們贊成使用不同形式的顯式常數，而把0僅留做整數常量。采用這些形式實際上指明了有關
值的用途，能起一點文檔作用。可惜的是，在C++ 里人們都已接受了用0 (而不是N U L L)表示
空指針。J a v a為解決這個問題采用了一種更好的方法，它定義了一個關鍵字n u l l，用來表示
一個對象引用實際上并沒有引用任何東西。
注釋
注釋是幫助程序讀者的一種手段。但是，如果在注釋中只說明代碼本身已經講明的事情，
或者與代碼矛盾，或是以精心編排的形式干擾讀者，那么它們就是幫了倒忙。最好的注釋是
簡潔地點明程序的突出特征，或是提供一種概觀，幫助別人理解程序。
不要大談明顯的東西。注釋不要去說明明白白的事，比如i + +能夠將i值加1等等。下面是我
們認為最沒有價值的一些注釋：
/*
default
*/
default:
break;
/* return SUCCESS */
return SUCCESS;
zerocount++; /* Increment zero entry counter */
/* Initialize " total" to "number-received" */
node->total = node->number-received ;
所有這些都該刪掉，它們不過是一些無謂的喧囂。
注釋應該提供那些不能一下子從代碼中看到的東西，或者把那些散布在許多代碼里的信
息收集到一起。當某些難以捉摸的事情出現時，注釋可以幫助澄清情況。如果操作本身非常
明了，重復談論它們就是畫蛇添足了：
這些注釋也都應該刪除，因為仔細選擇的名字已經攜帶著有關信息。
不要注釋差的代碼，重寫它。應該注釋所有不尋常的或者可能迷惑人的內容。但是如果注釋
的長度超過了代碼本身，可能就說明這個代碼應該修改了。下面的例子是一個長而混亂的注
釋和一個條件編譯的查錯打印語句，它們都是為了解釋一個語句：
/* If "result" i s 0 a match was found so return true
(non-zero).
Otherwise, "result" i s non-zero so return false (zero). */
#ifdef DEBUG
printf("w* isword returns ! result = %d\n" , ! result) ;
fflush(stdout);
#endif
return(! result) ;
否定性的東西很不好理解，應該盡量避免。在這里，部分問題來自一個毫無信息的變量名字
result。改用另一個更具說明性的名字matchfound之后，注釋就再沒有存在的必要，打
印語句也變得清楚了：
# ifdef DEBUG
printf ("*** isword returns matchfound = %d\n" , matchfound) ;
fflush(stdout) ;
#endif
return matchfound;
不要與代碼矛盾。許多注釋在寫的時候與代碼是一致的。但是后來由于修正錯誤，程序改變
了，可是注釋常常還保持著原來的樣子，從而導致注釋與代碼的脫節。
無論產生脫節的原因何在，注釋與代碼矛盾總會使人感到困惑。由于誤把錯誤注釋當真，
常常使許多實際查錯工作耽誤了大量時間。所以，當你改變代碼時，一定要注意保證其中的
注釋是準確的。
注釋不僅需要與代碼保持一致，更應該能夠支持它。下面的例子里的注釋是正確的，它
正確地解釋了后面兩行的用途。但細看又會發現它與代碼矛盾，注釋中談的是換行，而代碼
中說的則是空格：
time(&now) ;
strcpy(date, ctime(&now)) ;
/* get rid of trailing newline character copied from ctime */
i = 0 ;
while(date[i] >= ' ') i++;
date[il = 0;
一個可能的改進是采用慣用法重寫代碼：
time(&now) ;
strcpy(date, ctime(&now)) ;
/* get rid of trailing newline character copied from ctime */
for (i = 0; date[i] != '\n' ; i++)
date[ i ] = ' \ 0' ;
現在注釋和代碼一致了。但是這兩者都還可以進一步改進，應該寫得更直截了當些。這里要
解決的問題就是刪除函數ctime返回時放在字符串最后的換行字符。注釋里應該說明這個情
況，代碼也應該是做這件事：
time(&now) ;
strcpy(date, ctime(&now)) ;
/* ctime() puts newline at end of string ; delete it */
date[strlen(date)-l] = '\0' ;
最后這個表達式是在C語言里截去字符串最后字符的習慣寫法。現在代碼變短了，注釋也支持
它，解釋了為什么這個語句需要做。
澄清情況，不要添亂。注釋應該在困難的地方盡量幫助讀者，而不是給他們設置障礙。下面的
例子中遵循了我們為函數寫注釋的建議，解釋函數不尋常的特征。但是這里的函數是strcmp，
這是個標準的東西，具有人們熟悉的界面，它的不尋常特性對手頭工作來說根本不重要：
int strcmp(char *sl, char *s2)
/* string comparison routine returns -1 if s1 is */
/* above s2 in an ascending order list , 0 if equal */
/* 1 if s1 below s2 */
{
while(*sl==*s2) {
if(*sl=='\0')
return(0);
sl++;
s2++;
}
if (*s1 > *s2)
return(1) ;
return(-1) ;
}
如果真的需要用許多話來解釋出了什么事，這可能就說明了有關代碼應該重寫。上面的代碼
可以改進，但其中真正的問題在注釋，它幾乎有代碼本身那么長，而且也非常含糊(例如，什
么是這里的above？)。我們很難說這段代碼難以理解，但是，由于它實現的是一個標準函數，
它的注釋就應該在這方面有所幫助，應該概述其行為，告訴我們哪里有它原來的定義。下面
的注釋是合適的：
/* strcmp: return < 0 if sl<s2, > 0 if s1 > s2, 0 if
equal */
/* ANSI C, section 4.11.4.2 */
int strcmp(const char *s1, const char *s2)
{
. . .
}
學生常被告之應該注釋所有的內容。職業程序員也常被要求注釋他們的所有代碼。但是，
應該看到，盲目遵守這些規則的結果卻可能是丟掉了注釋的真諦。注釋是一種工具，它的作
用就是幫助讀者理解程序中的某些部分，而這些部分的意義不容易通過代碼本身直接看到。
我們應該盡可能地把代碼寫得容易理解。在這方面你做得越好，需要寫的注釋就越少。好的
代碼需要的注釋遠遠少于差的代碼。
學生常被告之應該注釋所有的內容。職業程序員也常被要求注釋他們的所有代碼。但是，
應該看到，盲目遵守這些規則的結果卻可能是丟掉了注釋的真諦。注釋是一種工具，它的作
用就是幫助讀者理解程序中的某些部分，而這些部分的意義不容易通過代碼本身直接看到。
我們應該盡可能地把代碼寫得容易理解。在這方面你做得越好，需要寫的注釋就越少。好的
代碼需要的注釋遠遠少于差的代碼。
我們談論的主要問題是程序設計的風格：具有說明性的名字、清晰的表達
式、直截了當的控制流、可讀的代碼和注釋，以及在追求這些內容時一致地使用某些規則和
慣用法的重要性。沒人會爭辯說這些是不好的。
但是，為什么要為風格而煞費苦心？只要程序能運行，誰管它看起來是什么樣子？把它
弄得漂亮點是不是花費了太多時間？這些規則難道沒有隨意性嗎？
我們的回答是：書寫良好的代碼更容易閱讀和理解，幾乎可以保證其中的錯誤更少。進
一步說，它們通常比那些馬馬虎虎地堆起來的、沒有仔細推敲過的代碼更短小。在這個拼命
要把代碼送出門、去趕上最后期限的時代，人們很容易把風格丟在一旁，讓將來去管它們吧。
但是，這很可能是一個代價非常昂貴的決定。如果對好風格問題重
視不夠，程序中哪些方面可能出毛病。草率的代碼是很壞的代碼，它不僅難看、難讀，而且
經常崩潰。
這里最關鍵的結論是：好風格應該成為一種習慣。如果你在開始寫代碼時就關心風格問
題，如果你花時間去審視和改進它，你將會逐漸養成一種好的編程習慣。一旦這種習慣變成
自動的東西，你的潛意識就會幫你照料許多細節問題，甚至你在工作壓力下寫出的代碼也會
更好。