6、if 語句對出錯的處理
———————————
我看見你說了，這有什麼好說的。還是先看一段程式**吧。
if ( ch >= '0' &&ch <= '9' )else
這種結構很不好，特別是如果「正常處理**」很長時，對於這種情況，最好不要用else
。先判斷錯誤，如：
if ( ch <'0' || ch >'9' )
/* 正常處理** */
......
這樣的結構，不是很清楚嗎？突出了錯誤的條件，讓別人在使用你的函式的時候，第一眼
就能看到不合法的條件，於是就會更下意識的避免。
7、標頭檔案中的#ifndef
——————————
千萬不要忽略了頭件的中的#ifndef，這是乙個很關鍵的東西。比如你有兩個c檔案，這兩
個c檔案都include了同乙個標頭檔案。而編譯時，這兩個c檔案要一同編譯成乙個可執行檔案
，於是問題來了，大量的宣告衝突。
還是把頭檔案的內容都放在#ifndef和#endif中吧。不管你的標頭檔案會不會被多個檔案引用
管你的標頭檔案會不會被多個檔案引用
，你都要加上這個。一般格式是這樣的：
#ifndef 《標識》
#define 《標識》
......
......
#endif
《標識》在理論上來說可以是自由命名的，但每個標頭檔案的這個「標識」都應該是唯一的。
標識的命名規則一般是頭檔名全大寫，前後加下劃線，並把檔名中的「.」也變成下劃
線，如：stdio.h
#ifndef _stdio_h_
#define _stdio_h_
......
#endif
（btw：預編譯有多很有用的功能。你會用預編譯嗎？）
（btw：預編譯有多很有用的功能。你會用預編譯嗎？）
8、在堆上分配記憶體
—————————
可能許多人對記憶體分配上的「棧 stack」和「堆 heap」還不是很明白。包括一些科班出身
的人也不明白這兩個概念。我不想過多的說這兩個東西。簡單的來講，stack上分配的記憶體
系統自動釋放，heap上分配的記憶體，系統不釋放，哪怕程式退出，那一塊記憶體還是在那裡
。stack一般是靜態分配記憶體，heap上一般是動態分配記憶體。
由malloc系統函式分配的記憶體就是從堆上分配記憶體。從堆上分配的記憶體一定要自己釋放。
用free釋放，不然就是術語——「記憶體洩露」（或是「記憶體漏洞」）—— memory leak。
於是，系統的可分配記憶體會隨malloc越來越少，直到系統崩潰。還是來看看「棧記憶體」和
「堆記憶體」的差別吧。
棧記憶體分配
—————
char*
allocstrfromstack()
堆記憶體分配
—————
char*
allocstrfromheap(int len)
對於第乙個函式，那塊pstr的內存在函式返回時就被系統釋放了。於是所返回的char*什麼
也沒有。而對於第二個函式，是從堆上分配記憶體，所以哪怕是程式退出時，也不釋放，所
以第二個函式的返回的記憶體沒有問題，可以被使用。但一定要呼叫free釋放，不然就是mem
ory leak！
在堆上分配記憶體很容易造成記憶體洩漏，這是c/c++的最大的「克星」，如果你的程式要穩定
，那麼就不要出現memory leak。所以，我還是要在這裡千叮嚀萬囑付，在使用malloc系統
蛑齦叮
程式設計修養 推薦
什麼是好的程式設計師？是不是懂得很多技術細節？還是懂底層程式設計？還是程式設計速度比較快？我覺得都不是。對於一些技術細節來說和底層的技術，只要看幫助，查資料就能找到，對於速度快，只要編得多也就熟能生巧了。我認為好的程式設計師應該有以下幾方面的素質 1 有專研精神，勤學善問 舉一反三。2 積極向上的態...
程式設計修養（四）
11 出錯資訊的處理 你會處理出錯資訊嗎？哦，它並不是簡單的輸出。看下面的示例 if p null 告別學生時代的程式設計吧。這種程式設計很不利於維護和管理，出錯資訊或是提示資訊，應該統一處理，而不是像上面這樣，寫成乙個 硬編碼 第10條對這方面的處理做了一部分說明。如果要管理錯誤資訊，那就要有以下...
程式設計修養（一）
什麼是好的程式設計師？是不是懂得很多技術細節？還是懂底層程式設計？還是程式設計速度比較快？我覺得都不是。對於一些技術細節來說和底層的技術，只要看幫助，查資料就能找到，對於速度快，只要編得多也就熟能生巧了。我認為好的程式設計師應該有以下幾方面的素質 1 有專研精神，勤學善問 舉一反三。2 積極向上的態...