Unix(Linux)C程式設計問題精粹(轉)[@more@]對於C語言,有人認為它已經落伍了.對於這個問題,仁者見仕,智者見智.的確,C++比C有更強大的諸多優勢.但C++是建立在C之上的.這也是Herbert Schildt所著的<>在全世界暢銷不衰的原因.更何況,要深入學習LINUX就必需要有相當的C功底.(這也是我搜集整理本文的根由:-)
現結合個人在程式設計中的體會,為使新手少走彎路,為老手錦上添花,因此無論你是使用C或C++程式設計,也無論你是程式設計的初學者還是成熟的專業人員,均會發現,本文將會對你有所收益.當然,我盡力寫得清晰易懂,又不古板.

=======================================
|版權宣告:你可以自由複製與分發本文件 |
|如果你要修改本文件或提出更好建議，請 |
|先通知文章的作者。而不要僅在公告欄中 |
|貼出。因為作者可能漏看。無論如何，都 |
|須保留本宣告。 |
| |
| |
| |

=======================================

文章目錄
第一章:前言
第二章:約定
第三章:開始任務
第四章:使用lint
第五章:使用make
第六章:優質無錯程式設計
第七章:除錯技術
第八章:其它更好的文件

第一章:前言

你可以在forum.linuxaid.com.cn上獲得此帖的文字.而其HTML版本正在趕製之中......
如果你是在一個月之後看到本文,那麼此文或許已經更新了:-)

第二章:約定

專業的源程書寫風格.
先看看世界級C大師的源程書寫風格.如 Steve Maguire 就有許多不錯的建議.

[]倡導使用易於理解的"匈牙利式"的命名約定.
所有的字元變數均以ch開始; 如: char ch_****;
所有的位元組變數均冠以b; 如: byte b_****;
所有的長字變數均冠以l; 如: long l_****;
所有的指標變數均冠以P; 如: char *p_ch_****;
建議型別派生出的基本名字之後加上一個以大寫字母開頭的"標籤".如:
分析 char **ppchMydata;
其讓人一眼就能看出它代表一個指向字元指標Mydata的指標.
"匈牙利式"命名的最大不足是難念:-(( .但相對於不是總統演講稿的C源程來說,這又算得了什麼?想想看以下的資料命名:
char a,b,c;
long d,e,f;
.
.
.
(反正我是不會再看下去了...)

[]倡導規範書寫.
如果你思如泉湧,而不去也不及顧慮書寫格式,那也沒關係.在將其交出去之前,用cb命令格式化你的源程.雖然源程的格式不會影響到你編譯結果的正確性,但切記,能讓其他的程式設計師能輕鬆地閱讀它.否則沒人會理你的.
關於cb命令的更多用法,可以用man cb來參考其手冊頁.
當然除了cb之外,還有更多更好的.但cb是你在任何UNIX(LINUX)上都找得到的.更何況它並不差.

第三章:開始任務

開始任務之前,先做個深呼吸!

[]其他文件你準備好了嗎?
你是不是除了C源程之外一無所有了嗎?兵馬未動,糧草先行.你必須先清楚該程式所要完成的功能.在開始寫程式之前,對程式的功能應有規範說明.書寫規範書和確知程式功能的一個方法是先編寫相應的操作手冊.如果你是一人單幹,勸你首先寫需求書.切記切記,這對你意味著事半功倍的大好事.
一個例項:我計劃為本行的信貸子功能模組打一個補丁.我用10周的時間用來寫規劃書,需求書,操作流程,使用說明等等文件.之後用2周的時間編寫程式,在初步測試(1周)後遞交給各信貸部門測試使用.然後根據反饋的資訊再更改相應文件,並根據文件修改源程.6個月後釋出正式版.

[]一定該遵循ANSI標準嗎?
如果你僅使用ANSI的標準首標檔案,恭喜你,你的程式有著全世界範圍內的廣泛支援和相容.光明無限.但你必須在通用與專用之間做出取捨,對不起,我幫不了你.
我的原則是:核心用ANSI,介面按需而取.這樣在轉換平臺時僅需另編使用者介面而已.實用至上嘛.
附:ANSI 標準C標頭檔案

是不是很寒酸? []再續前緣? 在得到新任務之後並在開始該新任務之前應馬上回想有哪些是曾經擁有的.舊調重彈遠比另起爐灶來的高效與環保. []是否該有自已的庫? 我的答案是應該有自已的特色庫,並與ANSI相容.與3.8不同的是,你僅需在源程式之後附上自已的專用庫就可以了.其次在有了自已的庫後,原始碼會很精煉的.不用去羨慕別人了吧. []要學會條件編譯.注意你的平臺特性.(高手的標誌?) 除非你確定你要寫的程式是在某特定的OS特定的硬體平臺而量身定做.否則應注意資料型別的長度,精度都是不同的,不要想當然.有時甚至是不同的編譯器的差異都要考慮考慮. .... ....(歡迎您來充實此處空白) .... 好了,在任務中,又有哪些細節呢? []我是不是葛郎臺? 不要那麼吝嗇.在源程式中加入詳盡的註釋以使自己和他人即使在許多年以後仍能讀明白它是什麼樣的程式. 用註釋行分離各個函式. []刪除不需要的程式碼時要小心. 一個好建議是:使用#ifdef DEL,而不是簡單地註釋掉甚至是粗暴地直接dd.如果你是使用/* ... */,但一旦要刪除的程式碼有很多行,或註釋中以有註釋時,這就可能不那麼好使了. []如何給源程式檔案命名? 表現特色且不與任何原有應用名相同.一個簡單地方法就是試試看,系統有什麼樣地反應? []一次只修改一個地方. []一次只編寫一個單一功能的函式。 []編寫通用程式. 只有當程式編寫完,並且完成了所需要的效能要求之後,再反過頭來最佳化該程式. []不要使用a.out作為結果.你大可以使用與源程相同的可執行檔名. []是否一定要用VI編輯? LINUX下有許多專用程式設計編輯器.它們能使你有更高的效率和更低的低階輸入錯誤,但我還是要勸你至少要熟練掌握VI.畢竟VI遍地開花. []協同作業.請相信,你不是在孤軍作戰.因此,你有必要熟練掌握一些其它的工具.如 .... ....(歡迎您來充實此處空白) ....

第四章:使用lint lint沒有你想象中的那樣糟糕.相反,一旦源程式形成了沒有LINT錯誤的形式,將很容易保持下去,並享受到如此而帶來的好處. []在cc(gcc)之前就應使用LINT. lint是一語法檢查程式,對於這個多嘴的婆婆來說,你應有足夠的耐心.雖然你知道自已在幹什麼,但在CC之前使用LINT總是一個好習慣. []lint有哪些特色? 在編譯之前使用lint的重要原因是LINT不但能發現ANSI C中的語法錯誤,而且也能指出潛在的問題或是難於移植於另一機器的程式碼問題.除了能指出簡單語法錯誤之外,LINUT還能基於以下原因指出另外的錯誤: A.無法達到的語句. B.沒有進入迴圈. C.沒有被使用的變數. D.函式引數從未使用. E.沒有賦值之前自動使用引數. F.函式在有些地方有返回值,但在其他地方不返回. G.函式呼叫在不同地方使得引數個數不同. H.錯誤使用結構指標. I.模糊使用運算子優先順序. 呵呵呵,挺有用的吧! []如何控制LINT的輸出? 有時LINT會有一大屏一大屏的警告資訊.但似乎並未指出錯誤.為了找出潛在的錯誤則需費心費力地瀏覽這些大量的警告資訊. 但如果你的程式會分出幾個獨立的模組,在初級啟動LINT時不要用可選項.當對這些模組進行更改或擴充時,可以忽略與程式碼無關的某些警告.為此可用以下選擇項: -h 對判別是否有錯,型別是否正確不給出啟發式測試. -v 不管函式中沒有定義的引數 -u 不管被使用的變數和函式沒有定義或定義了但沒有使用. []乾脆,在程式中插入指令來影響LINT執行.它看樣子有些像註釋. /*NOTREACHED*/ 不可達到的程式碼不給資訊說明. /*VARARGSn*/ 函式的變數個數不作通常的檢查,只檢查開始n個引數的資料型別. /*NOSTRUCT*/ 對下一個表示式不作嚴格型別檢查. /*ARGUSED*/ 下一函式中,不給出沒被使用引數的警告資訊. /*LINTLIBRARY*/ 置於檔案的開頭,它將不給出沒被使用函式的警告資訊. 關於LINT的更多用法,請用man lint來獲知. 第五章:使用make []什麼是make? Unix(Linux)是一個天生的開發平臺,我為此感到高興.make是一個強力的工具.它能自動跟蹤相互依賴的原始碼塊並組成一程式,使得很容易建立一可執行程式.Make就是這種有依賴關係的部分和程式碼之間所作的規格說明. [] 所有的程式都要使用make? 是的.儘管你只有幾個簡單的模組,但你需要有一種結構來支援它從簡單走向複雜.除非你的程式已經蓋棺定論. []Makefile由哪些組成? Makefile由以下幾個部分組成: 註釋. ^^^^ 使用#符號插入.make將忽略#之後的任何內容以及其後的RETURN鍵. 變數. ^^^^ make允許定義與SHELL變數類似的有名變數.比如,你定義了SOURCES=prog.c,那麼該變數的值$(SCOURES)就包含了原始檔名. 依賴關係. ^^^^^^^^ 左邊是目標模組，後接一冒號.再接與該模組有依賴關係的模組. 命令. ^^^^ 以TAB鍵開始(即使用相同數量的空格也不能代替它). []Makefile示例下面介紹一個簡單的示例來說明make的用法.假設你的程式有兩個原始檔main.c和myc.c,一個位於子目錄include下的標頭檔案myhead.h,一個庫由三個原始檔myrout1.c,myrout2.c,myrout3.c產生. 其makefile檔案為: #一個基本的MAKEFILE檔案. #其中包括個人的標頭檔案和個人庫. HEADERS=include/myhead.h SOURCES=main.c myc.c PRODUCT=$(HOME)/bin/tool LIB=myrout.a LIBSOURES=myrout1.c myrout2.c myrout3.c CC=cc CFLAGS=-g all:$(PRODUCT) $(PRODUCT):$(SOURCES) $(CC)$(CFLAGS) -o $(PRODUCT)$(SOURCES) lint:$(PRODUCT) lint $(SOURCES)$(LIBSOURCES) 哈哈,挺象SHELL程式設計的.如果你與我一樣使用LINUX下的gcc,那麼只要把上面的CC=cc改為CC=gcc即可.怎麼樣,想來一個更復雜點的嗎? []一個更為複雜的Makefile 你是否注意到,在上例中,只要啟動make,就會重新編譯所有原始碼. 如果你能看懂以下的makefile,恭喜恭喜,你通關了. #一個更為複雜的makefile HEADERS=include/myhead.h SOURES=main.c myc.c OBJECTS=main.c myc.c PRODUCT=$(HOME)/bin/tool LIB=myrout.a LIBSOURCES=myrout1.c myrout2.c myrout3.c LIBOBJECTS=$(LIB)(myrout1.o)$(LIB)(myrout2.o)$(LIB)(myrout3.o) INCLUDE=include CC=cc CFLAGS=-g -Xc LINT=lint LINTFLAGS=-Xc all:$(PRODUCT) $(PRODUCT):$(OBJECTS)$(LIB) $(CC)(CFLAGS)-o$(PRODUCT)$(OBJECTS)$(LIB) .c.o: $(HEADERS) $(CC)$(CFLAGS) -c I$(INCLUDE)$< $(LIB):$(HEADERS)$(LIBSOURCES) $(CC) $(CFLAGS) -c $(?:.o=.c) ar rv $(LIB) $? rm $? .c.c:; lint: $(PRODUCT) $(LINT)$(LINIFLAGS)$(SOURCES)$LIBSOURCES) 第六章:優質無錯程式設計 親愛的,檢查一下,你是否注意到了以下的細節?也就是說,你是否是一個合格的,能編寫優質無錯程式碼的程式設計師?要永遠記住,編寫無錯程式碼是程式設計師的責任,而不是測試員.(摘錄於本人的"細節頁",因此本節將永遠不會保持完整,歡迎您來充實她) []所有程式設計師至少出現過的一個錯誤: if(a=3){......}如果a等於3,那麼...... 你至少要養成這樣的習慣:當判斷一個變數與一個常量是否相等時,將常量寫在前面.這樣即使你一不小心寫成這樣:if(3=a){......}在cc 之前就可以很容易發現它. []老調重彈:邏輯運算子的優先權. 我不願多嘴.總之,如果你一定要編寫如下程式碼時: if(a&0x1&&b&0x2){......} 你的手頭最好有一本詳盡的指南.或者你是這方面的專家. []儘量不使用int資料型別. 這僅是一個忠告.你大可使用char,short,long資料型別.若干年以後,當你成長為高手之時,你會發現此時我的良苦用心. []對於非整型函式一定要完整定義. 如 long float jisuan(char chArr[],int chNum) { long float lMydata; ... ... return(lMydata); } []對於非整型函式的輸入要當心. 如 long float lfNum; ... ... scanf("%lf",&lfNum); []float 型的有效數字為7位.當多於7位時,第8位及以後的位將不準確,可以將其定義為long float型. []檔案的輸入出盡量採用fread fwrite函式.只有當另有用途時才用fprintf fscanf 函式. []對於陣列及字串的比較操作時要確認以'結束. 第七章:除錯技術 除錯技術在本文中不太好說,之所以將其獨立成章是想套用M$的老話:"在下一版本中將會做得更好":-((.其實這類文章在全國各大BBS上滿天飛. 在此我只想說說程式設計師的應盡職責之一:在程式中使用斷言. ~~~~ []既要維護程式的交付版本,又要維護程式的除錯版本,這時可以利用斷言補救. []要使用斷言對函式引數進行確認. []要從程式中刪除無定義的特性,或者在程式中使用斷言來檢查出無定義特性的非法使用. []不要浪費別人的時間,詳細說明不清楚的斷言. []消除所做的隱式假定,或者利用斷言檢查其正確性. []利用斷言來檢查不可能發生的情況. 一個例項:我在我的源程式中都使用斷言.在本人所編制的全國電子匯兌模糊檢索功能模組測試中,前臺人員氣喘吁吁地告訴我,螢幕上出現了不認識的英文.我說最前面的是哪幾個數字,然後根據此數字查閱斷言文件,原來是前日日終未正常結束,經查只有半個庫.這種情況極少發生,但不是不可能發生.使用斷言能及時正確地判別是否是程式的錯誤還是外部的因素.因此使用斷言,是將錯誤消滅在發生錯誤之前的一個極其重要的手法.這也是判斷一個程式設計師是否具備良好素質的一個方面. 第八章:其它更好的文件 <> Kenneth H. Rosen ...etc. <> UNIX Software Operation. <> Herbert Schildt. <> Steve Maguire. <> Daniel Barlow. <> 譚浩強. NOTE:本人的<>相信能在8周後能與讀者見面.它詳盡細緻的討論了低階庫curses,視窗,panel庫,menu庫,form庫,TAM變換庫等的使用和注意事項,並給出了可用的例項.由於全文龐大複雜,所以寫得慢了些.(慢工出細活?)敬請見諒.此外,由於本人的經驗所限,本人所討論的所有東西有可能是過時的,如果你也是為金融,郵電,證券等只用字元終端的行業開發應用的話,你就找對了.與此相反,如果你是新潮一族的話,請將這些難啃的東西DEL掉.呵呵....

Unix(Linux)C程式設計問題精粹(轉)

相關文章