程式設計修養(二) (轉)
1、版權和版本
———————
好的員會給自己的每個,每個,都註上版權和版本。
對於C/C++的檔案,檔案頭應該有類似這樣的註釋:
/************************************************************************
*
* 檔名work.c
*
* 檔案描述:通訊函式集
*
* 建立人: Hao Chen, 年2月3日
*
* 版本號:1.0
*
* 修改記錄:
*
************************************************************************/
而對於函式來說,應該也有類似於這樣的註釋:
/*================================================================
*
* 函 數 名:XXX
*
* 參 數:
*
* type name [IN] : descripts
*
* 功能描述:
*
* ..............
*
* 返 回 值:成功TRUE,失敗FALSE
*
* 丟擲異常:
*
* 作 者:ChenHao 2003/4/2
*
================================================================*/
這樣的描述可以讓人對一個函式,一個檔案有一個總體的認識,對程式碼的易讀性和易維護性有很大的好處。這是好的作品產生的開始。
2、縮排、空格、換行、空行、對齊
————————————————
i) 縮排應該是每個程式都會做的,只要學程式過程式就應該知道這個,但是我仍然看過不縮排的程式,或是亂縮排的程式,如果你的公司還有寫程式不縮排的程式設計師,請毫不猶豫的開除他吧,並以破壞原始碼罪起訴他,還要他賠償讀過他程式的人的精神損失費。縮排,這是不成文規矩,我再重提一下吧,一個縮排一般是一個TAB鍵或是4個空格。(最好用TAB鍵)
ii) 空格。空格能給程式代來什麼損失嗎?沒有,有效的利用空格可以讓你的程式讀進來更加賞心悅目。而不一堆擠在一起。看看下面的程式碼:
ha=(ha*128+*key++)%tabPtr->size;
ha = ( ha * 128 + *key++ ) % tabPtr->size;
有空格和沒有空格的感覺不一樣吧。一般來說,語句中要在各個運算子間加空格,函式時,要以各個引數間加空格。如下面這種加空格的和不加的:
if ((hProc=OpenProcess(PROCESS_ALL_ACCESS,FALSE,pid))==NULL){
}
if ( ( hProc = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid) ) == NULL ){
}
iii) 換行。不要把語句都寫在一行上,這樣很不好。如:
for(i=0;i
我拷,這種即無空格,又無換行的程式在寫什麼啊?加上空格和換行吧。
for ( i=0; i
( a[i] < 'a' || a[i] > 'z' ) ) {
break;
}
}
好多了吧?有時候,函式引數多的時候,最好也換行,如:
CreateProcess(
NULL,
cmuf,
NULL,
NULL,
bInhH,
dwCrtFlags,
envbuf,
NULL,
&siStartInfo,
&prInfo
);
條件語句也應該在必要時換行:
if ( ch >= '0' || ch <= '9' ||
ch >= 'a' || ch <= 'z' ||
ch >= 'A' || ch <= 'Z' )
iv) 空行。不要不加空行,空行可以區分不同的程式塊,程式塊間,最好加上空行。如:
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 |= MSCAVA_PROC;
return(0);
v) 對齊。用TAB鍵對齊你的一些變數的宣告或註釋,一樣會讓你的程式好看一些。如:
typedef struct _pt_man_t_ {
int numProc; /* 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 */
D 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;
怎麼樣?感覺不錯吧。
這裡主要講述瞭如果寫出讓人賞心悅目的程式碼,好看的程式碼會讓人的心情愉快,讀起程式碼也就不累,工整、整潔的程式程式碼,通常更讓人歡迎,也更讓人稱道。現在的空間這麼大,不要讓你的程式碼擠在一起,這樣它們會抱怨你虐待它們的。好了,用“縮排、空格、換行、空行、對齊”裝飾你的程式碼吧,讓他們從沒有秩序的土匪中變成一排排整齊有秩序的正規部隊吧。
3、程式註釋
——————
養成寫程式註釋的習慣,這是每個程式設計師所必須要做的工作。我看過那種幾千行,卻居然沒有一行註釋的程式。這就如同在公路上駕車卻沒有路標一樣。用不了多久,連自己都不知道自己的意圖了,還要花上幾倍的時間才看明白,這種浪費別人和自己的時間的人,是最為可恥的人。
是的,你也許會說,你會寫註釋,真的嗎?註釋的書寫也能看出一個程式設計師的功底。一般來說你需要至少寫這些地方的註釋:檔案的註釋、函式的註釋、變數的註釋、演算法的註釋、功能塊的程式註釋。主要就是記錄你這段程式是幹什麼的?你的意圖是什麼?你這個變數是用來做什麼的?等等。
不要以為註釋好寫,有一些演算法是很難說或寫出來的,只能意會,我承認有這種情況的時候,但你也要寫出來,正好可以訓練一下自己的表達能力。而表達能力正是那種悶頭搞技術的技術人員最缺的,你有再高的技術,如果你表達能力不行,你的技術將不能得到充分的發揮。因為,這是一個團隊的時代。
好了,說幾個註釋的技術細節:
i) 對於行註釋(“//”)比塊註釋(“/* */”)要好的說法,我並不是很同意。因為一些老版本的C並不支援行註釋,所以為了你的程式的移植性,請你還是儘量使用塊註釋。
ii) 你也許會為塊註釋的不能巢狀而不爽,那麼你可以用預編譯來完成這個功能。使用“#if 0”和“#endif”括起來的程式碼,將不被編譯,而且還可以巢狀。
4、函式的[in][out]引數
———————————
我經常看到這樣的程式:
FuncName(char* str)
{
int len = strlen(str);
.....
}
char*
GetUserName(struct user* pUser)
{
return pUser->name;
}
不!請不要這樣做。
你應該先判斷一下傳進來的那個指標是不是為空。如果傳進來的指標為空的話,那麼,你的一個大的就會因為這一個小的函式而崩潰。一種更好的技術是使用斷言(assert),這裡我就不多說這些技術細節了。當然,如果是在C++中,引用要比指標好得多,但你也需要對各個引數進行檢查。
寫有引數的函式時,首要工作,就是要對傳進來的所有引數進行合法性檢查。而對於傳出的引數也應該進行檢查,這個動作當然應該在函式的外部,也就是說,呼叫完一個函式後,應該對其傳出的值進行檢查。
當然,檢查會浪費一點時間,但為了整個系統不至於出現“操作”或是“Core Dump”的系統級的錯誤,多花這點時間還是很值得的。
5、對系統呼叫的返回進行判斷
——————————————
繼續上一條,對於一些系統呼叫,比如開啟檔案,我經常看到,許多程式設計師對fopen返回的指標不做任何判斷,就直接使用了。然後發現檔案的內容怎麼也讀出不,或是怎麼也寫不進去。還是判斷一下吧:
fp = fopen("log.txt", "a");
if ( fp == NULL ){
printf("Error: open file error
");
return FALSE;
}
其它還有許多啦,比如:socket返回的socket號,malloc返回的。請對這些系統呼叫返回的東西進行判斷。
?id=18269">
(版權所有,轉載時請註明出處和作者資訊)
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10752019/viewspace-956443/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 程式設計修養(一) (轉)程式設計
- 程式設計修養(三) (轉)程式設計
- 程式設計修養(五) (轉)程式設計
- 程式設計修養(六) (轉)程式設計
- 程式設計修養(四) (轉)程式設計
- 程式設計修養(七) (轉)程式設計
- 程式設計師的自我修養程式設計師
- 程式設計師修煉之道—程式設計師如何提高自我修養(2)程式設計師
- 程式設計師修煉之道——程式設計師如何提高自我修養(1)程式設計師
- iOS 程式設計師的自我修養 — 讀《程式設計師的自我修養 連結、裝載與庫》iOS程式設計師
- 程式設計師如何提高自我修養(4)程式設計師
- 程式設計師的自我修養之全棧程式設計師程式設計師全棧
- 程式設計師自我修養之程式設計經驗總結程式設計師
- 一個野生程式設計師的自我修養程式設計師
- 程式設計師的科技道德修養 - idlewords程式設計師
- 淺談程式設計師的數學修養程式設計師
- 《程式設計師自我修養》讀書筆記程式設計師筆記
- 《程式設計師的自我修養》-讀書筆記程式設計師筆記
- 程式設計師的自我修養-編譯連結程式設計師編譯
- 讀書筆記 - 《程式設計師的自我修養》筆記程式設計師
- 《程式設計師的自我修養》讀書總結程式設計師
- 程式設計師的自我修養:溫故而知新程式設計師
- 《程式設計師的自我修養》筆記(二)——裝載與動態連結程式設計師筆記
- 程式設計師的自我修養筆記之裝載程式設計師筆記
- 【程式設計師的自我修養①】iOS記憶體管理程式設計師iOS記憶體
- 給每個菜鳥程式設計師的修養之道程式設計師
- 產品經理看程式設計師的自我修養程式設計師
- 《程式設計師的自我修養》(三)——庫與執行庫程式設計師
- 很認真的談一談程式設計師的自我修養程式設計師
- 很認真地聊一聊程式設計師的自我修養程式設計師
- 很認真的聊一聊程式設計師的自我修養程式設計師
- 從程式設計到養生程式設計程式設計
- 轉贈《程式設計師的職業素養》程式設計師
- 《程式設計師的自我修養筆記之靜態連結》程式設計師筆記
- 程式設計師自我修養之實現自我的10大方法程式設計師
- 編寫簡練程式碼是程式設計師的職業修養之本程式設計師
- 遊戲設計師的自我修養(三):理解玩家遊戲設計師
- 《程式設計師的自我修養》(一)——編譯與靜態連結程式設計師編譯