我拷，這種即無空格，又無換行的程序在寫什么啊?加上空格和換行吧。

　　for ( i=0; i

　　if ( ( a[i] < ’0’ || a[i] > ’9’ ) &&

　　( a[i] < ’a’ || a[i] > ’z’ ) ) {

　　break;

　　}

　　}

　　好多了吧?有時候，函數(shù)參數(shù)多的時候，最好也換行，如：

　　CreateProcess(

　　NULL,

　　cmdbuf,

　　NULL,

　　NULL,

　　bInhH,

　　dwCrtFlags,

　　envbuf,

　　NULL,

　　&siStartInfo,

　　&prInfo

　　);

　　條件語句也應該在必要時換行：

　　if ( ch >= ’0’ || ch <= ’9’ ||

　　ch >= ’a’ || ch <= ’z’ ||

　　ch >= ’A’ || ch <= ’Z’ )

　　iv) 空行。不要不加空行，空行可以區(qū)分不同的程序塊，程序塊間，最好加上空行。如：

　　HANDLE hProcess;

　　PROCESS_T procInfo;

　　/* open the process handle */

　　if((hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid)) == NULL)

　　{

　　return LSE_MISC_SYS;

　　}

　　memset(&procInfo, 0, sizeof(procInfo));

　　procInfo.idProc = pid;

　　procInfo.hdProc = hProcess;

　　procInfo.misc |= MSC***A_PROC;

　　return(0);

　　v) 對齊。用TAB鍵對齊你的一些變量的聲明或注釋，一樣會讓你的程序好看一些。如：

　　typedef struct _pt_man_t_ {

　　int numProc; /* Number of processes */

　　int maxProc; /* Max Number of processes */

　　int maxProc; /* Max Number of processes */

　　int numEvnt; /* Number of events */

　　int maxEvnt; /* Max Number of events */

　　HANDLE* pHndEvnt; /* Array of events */

　　DWORD timeout; /* Time out interval */

　　HANDLE hPipe; /* Namedpipe */

　　TCHAR usr[MAXUSR];/* User name of the process */

　　int numMsg; /* Number of Message */

　　int Msg[MAXMSG];/* Space for intro process communicate */

　　} PT_MAN_T;

　　怎么樣?感覺不錯吧。

　　這里主要講述了如果寫出讓人賞心悅目的代碼，好看的代碼會讓人的心情愉快，讀起代碼

　　也就不累，工整、整潔的程序代碼，通常更讓人歡迎，也更讓人稱道。現(xiàn)在的硬盤空間這

　　么大，不要讓你的代碼擠在一起，這樣它們會抱怨你虐待它們的。好了，用“縮進、空格

　　、換行、空行、對齊”裝飾你的代碼吧，讓他們從沒有秩序的土匪中變成一排排整齊有秩

　　序的正規(guī)部隊吧。

　　3、程序注釋

　　——————

　　養(yǎng)成寫程序注釋的習慣，這是每個程序員所必須要做的工作。我看過那種幾千行，卻居然

　　沒有一行注釋的程序。這就如同在公路上駕車卻沒有路標一樣。用不了多久，連自己都不

　　知道自己的意圖了，還要花上幾倍的時 間才看明白，這種浪費別人和自己的時 間的人，是

　　最為可恥的人。

　　是的，你也許會說，你會寫注釋，真的嗎?注釋的書寫也能看出一個程序員的功底。一般

　　來說你需要至少寫這些地方的注釋：文件的注釋、函數(shù)的注釋、變量的注釋、算法的注釋

　　、功能塊的程序注釋。主要就是記錄你這段程序是干什么的?你的意圖是什么?你這個變

　　量是用來做什么的?等等。

　　不要以為注釋好寫，有一些算法是很難說或寫出來的，只能意會，我承認有這種情況的時

　　候，但你也要寫出來，正好可以訓練一下自己的表達能力。而表達能力正是那種悶頭搞技

　　術的技術人員最缺的，你有再高的技術，如果你表達能力不行，你的技術將不能得到充分

　　的發(fā)揮。因為，這是一個團隊的時代。

　　好了，說幾個注釋的技術細節(jié)：

　　i) 對于行注釋(“//”)比塊注釋(“/* */”)要好的說法，我并不是很同意。因為一

　　些老版本的C編譯器并不支持行注釋，所以為了你的程序的移植性，請你還是盡量使用塊注

　　釋。

　　ii) 你也許會為塊注釋的不能嵌套而不爽，那么你可以用預編譯來完成這個功能。使用“#

　　if 0”和“#endif”括起來的代碼，將不被編譯，而且還可以嵌套。

　　4、函數(shù)的[in][out]參數(shù)

　　———————————

　　我經(jīng)常看到這樣的程序：

　　FuncName(char* str)

　　{

　　int len = strlen(str);

　　.....

　　}

　　char*

　　GetUserName(struct user* pUser)

　　{

　　return pUser->name;

　　}

　　不!請不要這樣做。

　　你應該先判斷一下傳進來的那個指針是不是為空。如果傳進來的指針為空的話，那么，你

　　的一個大的系統(tǒng)就會因為這一個小的函數(shù)而崩潰。一種更好的技術是使用斷言(assert)

　　，這里我就不多說這些技術細節(jié)了。當然，如果是在C 中，引用要比指針好得多，但你也

　　需要對各個參數(shù)進行檢查。

　　寫有參數(shù)的函數(shù)時，首要工作，就是要對傳進來的所有參數(shù)進行合法性檢查。而對于傳出

　　的參數(shù)也應該進行檢查，這個動作當然應該在函數(shù)的外部，也就是說，調用完一個函數(shù)后

　　，應該對其傳出的值進行檢查。

　　當然，檢查會浪費一點時 間，但為了整個系統(tǒng)不至于出現(xiàn)“非法操作”或是“Core Dump”

　　的系統(tǒng)級的錯誤，多花這點時 間還是很值得的。

　　5、對系統(tǒng)調用的返回進行判斷

　　——————————————

　　繼續(xù)上一條，對于一些系統(tǒng)調用，比如打開文件，我經(jīng)常看到，許多程序員對fopen返回的

　　指針不做任何判斷，就直接使用了。然后發(fā)現(xiàn)文件的內容怎么也讀出不，或是怎么也寫不

　　進去。還是判斷一下吧：

　　fp = fopen("log.txt", "a");

　　if ( fp == NULL ){

　　printf("Error: open file error\n");

　　return FALSE;

　　}

　　其它還有許多啦，比如：socket返回的socket號，malloc返回的內存。請對這些系統(tǒng)調用

　　返回的東西進行判斷。

　　1、版權和版本

　　———————

　　好的程序員會給自己的每個函數(shù)，每個文件，都注上版權和版本。

　　對于C/C 的文件，文件頭應該有類似這樣的注釋：

　　/************************************************************************

　　*

　　* 文件名：network.c

　　*

　　* 文件描述：網(wǎng)絡通訊函數(shù)集

　　*

　　* 創(chuàng)建人： Hao Chen, 2003年2月3日

　　*

　　* 版本號：1.0

　　*

　　* 修改記錄：

　　*

　　*

　　************************************************************************/

　　而對于函數(shù)來說，應該也有類似于這樣的注釋：

　　/*================================================================

　　*

　　* 函 數(shù) 名：XXX

　　*

　　* 參 數(shù)：

　　*

　　* type name [IN] : descripts

　　*

　　* 功能描述:

　　*

　　* ..............

　　*

　　* 返 回 值：成功TRUE，失敗FALSE

　　*

　　* 拋出異常：

　　*

　　* 作 者：ChenHao 2003/4/2

　　*

　　*