編者按：這是國外程序員Al katib總結的一些編程習慣。

1. 動(dòng)手編碼之前，你需要對要編碼實(shí)現的解決方案有一個(gè)正式的或粗略的設計。永遠不要在沒(méi)有任何設計的前提下就開(kāi)始編碼，除非所編代碼不重要。

2. 優(yōu)秀的代碼文檔跟編程語(yǔ)言知識一樣重要。在代碼源文件中，為每個(gè)主要的代碼段添加注釋?zhuān)忉尨a的基本邏輯。最好注明程序的構建和修改日期，以及修改的原因也是非常有必要的。

　　3. 維護程序的各個(gè)版本同樣重要。當前有些編程工具都自帶一個(gè)版本管理工具。無(wú)論你什么時(shí)候改變自己的程序，它們都會(huì )將其保存為.bak文件。

　　我的方法是為每個(gè)程序維護三個(gè)不同的版本。比如說(shuō)，我有一個(gè)名為program.c的文件，這個(gè)文件同時(shí)也被其他項目組成員使用。我把這個(gè)文件復制為 program.c.old作為備份文件，并且當我修改時(shí)，我會(huì )備份另一個(gè)名為program.c.wrk的副本文件。當成功完成修改時(shí)替換 program.c.wrk文件。

　　你還可以給自己的程序版本添加一個(gè)日期或一些注釋?zhuān)駊rogram260505.c或programReadFnWrking.c。

　　4. 如果工程包含多個(gè)源文件，則聲稱(chēng)一個(gè)README文件，注明每個(gè)源文件、數據文件、臨時(shí)文件以及日志文件(如果有的話(huà))的作用。你還可以注明編譯和運行步驟。

　　5. 有時(shí)候，你一定想知道為什么IF語(yǔ)句沒(méi)有得到預想的結果?？赡苣闶褂玫氖堑忍?，也就是“=”，而不是條件判定符號“==”。一個(gè)比較好的辦法是用相反的順序寫(xiě)條件語(yǔ)句。因此，你的條件語(yǔ)句應該如下：

　　if(10==i)…因此，如果你錯誤地寫(xiě)成了單個(gè)等于號，在編譯的時(shí)候也能檢查出來(lái)并報錯。

　　6.使用循環(huán)和條件語(yǔ)句時(shí)，先把左右括號對應起來(lái)，然后再在里面寫(xiě)其他語(yǔ)句。也就是：

代碼: 1 for(int i=0;i<10;i++)2 {4 printf(“i=%dn”,i);3 } 　　注：每一行開(kāi)頭的數字表明寫(xiě)循環(huán)代碼的順序。

　　7. 避免使用幻數（magic numbers）。例如，不要寫(xiě)

代碼: circleArea = 3.14 * pow(radius,2); 而要使用如下代碼：

代碼: #define PI 3.14 circleArea = PI * pow(radius,2); 　　
　　8. 使用有意義的變量和函數名稱(chēng)。例如，使用‘radius’來(lái)代替圓的半徑，而不是用‘r’來(lái)表示。同樣，函數名‘calculateArea’要比其他任 何隱晦的縮寫(xiě)要好得多。匆忙之下，我們也許會(huì )使用縮寫(xiě)的變量名，但一開(kāi)始節省時(shí)間的話(huà)，之后會(huì )浪費更多的時(shí)間，去猜測縮寫(xiě)變量名代表什么。（編注：）

　　9. 為后面的調試使用打印語(yǔ)句，這是個(gè)好習慣。但是，當完成最后代碼后，去掉這些語(yǔ)句，有時(shí)也是一項危險的任務(wù)。添加一個(gè)方法，用于輸出調試信息。當最終版本生成時(shí)，只要把這個(gè)方法注釋掉就行。因此，只在一個(gè)地方做修改就可以了。

　　10. 代碼編寫(xiě)完之后，開(kāi)始優(yōu)化代碼。之前聲明的一些變量，現在可能沒(méi)用了。同樣，并不依賴(lài)循環(huán)的一些聲明可以移到循環(huán)模塊之外去。扎實(shí)的編譯知識同樣會(huì )對以后的代碼優(yōu)化有所幫助。

　　11. 對自己的操作系統和硬件要有足夠的了解，你可以從資源占用等方面提升程序的性能。

　　12. 編寫(xiě)代碼時(shí)要合理使用縮進(jìn)，以使代碼清晰可讀。

　　13. 把項目文件放到SOURCE、HEADERS、MAKE、EXES等不同的文件夾中。

　　14. 研究別人編寫(xiě)的代碼。這可以讓你學(xué)習到新的編程技術(shù)，以及他們解決和你相同的任務(wù)時(shí)所使用的方法。

　　15. 最后一條（但不是最不重要的一條)，備份源代碼文件，這樣當硬盤(pán)出錯或相同的問(wèn)題發(fā)生時(shí)，不至于前功盡棄。

　　附加：補充一條，堅持使用一種命名模式。如果你打算用匈牙利命名法，那就堅持并廣泛使用，否則將適得其反。參見(jiàn)微軟資深工程師 Eric Lippert 的這篇文章《閱讀代碼不簡(jiǎn)單》。

　　編者后話(huà)

　　編程的好習慣應不止這15條，也許您不認同上文中的某些觀(guān)點(diǎn)，請標出相應序號，并說(shuō)明其不足之處。另外，非常歡迎大家補充分享您的好習慣。