15個(gè)編程好習(xí)慣.doc

15個(gè)編程好習(xí)慣編者按：這是國外程序員Al katib總結(jié)的一些編程習(xí)慣。1. 動(dòng)手編碼之前，你需要對(duì)要編碼實(shí)現(xiàn)的解決方案有一個(gè)正式的或粗略的設(shè)計(jì)。永遠(yuǎn)不要在沒有任何設(shè)計(jì)的前提下就開始編碼，除非所編代碼不重要。2. 優(yōu)秀的代碼文檔跟編程語言知識(shí)一樣重要。在代碼源文件中，為每個(gè)主要的代碼段添加注釋，解釋代碼的基本邏輯。最好注明程序的構(gòu)建和修改日期，以及修改的原因也是非常有必要的。3. 維護(hù)程序的各個(gè)版本同樣重要。當(dāng)前有些編程工具都自帶一個(gè)版本管理工具。無論你什么時(shí)候改變自己的程序，它們都會(huì)將其保存為.bak文件。我的方法是為每個(gè)程序維護(hù)三個(gè)不同的版本。比如說，我有一個(gè)名為program.c的文件，這個(gè)文件同時(shí)也被其他項(xiàng)目組成員使用。我把這個(gè)文件復(fù)制為program.c.old作為備份文件，并且當(dāng)我修改時(shí)，我會(huì)備份另一個(gè)名為program.c.wrk的副本文件。當(dāng)成功完成修改時(shí)替換program.c.wrk文件。你還可以給自己的程序版本添加一個(gè)日期或一些注釋，像program260505.c或programReadFnWrking.c。4. 如果工程包含多個(gè)源文件，則創(chuàng)建一個(gè)README文件，注明每個(gè)源文件、數(shù)據(jù)文件、臨時(shí)文件以及日志文件(如果有的話)的作用。你還可以注明編譯和運(yùn)行步驟。5. 有時(shí)候，你一定想知道為什么IF語句沒有得到預(yù)想的結(jié)果?？赡苣闶褂玫氖堑忍?hào)，也就是“=”，而不是條件判定符號(hào)“=”。一個(gè)比較好的辦法是用相反的順序?qū)憲l件語句。因此，你的條件語句應(yīng)該如下：if(10=i)因此，如果你錯(cuò)誤地寫成了單個(gè)等于號(hào)，在編譯的時(shí)候也能檢查出來并報(bào)錯(cuò)。6.使用循環(huán)和條件語句時(shí)，先把左右括號(hào)對(duì)應(yīng)起來，然后再在里面寫其他語句。也就是：代碼:1 for(int i=0;i10;i+) 2 4 printf(“i=%dn”,i); 3 注：每一行開頭的數(shù)字表明寫循環(huán)代碼的順序。7. 避免使用幻數(shù)（magic numbers）。例如，不要寫代碼:circleArea = 3.14 * pow(radius,2);而要使用如下代碼：代碼:#define PI 3.14 circleArea = PI * pow(radius,2);8. 使用有意義的變量和函數(shù)名稱。例如，使用radius來代替圓的半徑，而不是用r來表示。同樣，函數(shù)名calculateArea要比其他任何隱晦的縮寫要好得多。匆忙之下，我們也許會(huì)使用縮寫的變量名，但一開始節(jié)省時(shí)間的話，之后會(huì)浪費(fèi)更多的時(shí)間，去猜測(cè)縮寫變量名代表什么。（編注：）9. 為后面的調(diào)試使用打印語句，這是個(gè)好習(xí)慣。但是，當(dāng)完成最后代碼后，去掉這些語句，有時(shí)也是一項(xiàng)危險(xiǎn)的任務(wù)。添加一個(gè)方法，用于輸出調(diào)試信息。當(dāng)最終版本生成時(shí)，只要把這個(gè)方法注釋掉就行。因此，只在一個(gè)地方做修改就可以了。10. 代碼編寫完之后，開始優(yōu)化代碼。之前聲明的一些變量，現(xiàn)在可能沒用了。同樣，并不依賴循環(huán)的一些聲明可以移到循環(huán)模塊之外去。扎實(shí)的編譯知識(shí)同樣會(huì)對(duì)以后的代碼優(yōu)化有所幫助。11. 對(duì)自己的操作系統(tǒng)和硬件要有足夠的了解，你可以從資源占用等方面提升程序的性能。12. 編寫代碼時(shí)要合理使用縮進(jìn)，以使代碼清晰可讀。13. 把項(xiàng)目文件放到SOURCE、HEADERS、MAKE、EXES等不同的文件夾中。14. 研究別人編寫的代碼。這可以讓你學(xué)習(xí)到新的編程技術(shù)，以及他們解決和你相同的任務(wù)時(shí)所使用的方法。15. 最后一條（但不是最不重要的一條)，備份源代碼文件，這樣當(dāng)硬盤出錯(cuò)或相同的問題發(fā)生時(shí)，不至于前功盡棄。附加：補(bǔ)充一條，堅(jiān)持使用一種命名模式。如果你打算用匈牙利命名法，那就堅(jiān)持并廣泛使用，否則將適得其反。參見微軟資深工程師 Eric Lippert 的這篇文章閱讀代碼不簡單。編者后話編程的好習(xí)慣應(yīng)不止這15條，也許您不認(rèn)同上文中的某些觀點(diǎn)，請(qǐng)標(biāo)出相應(yīng)序號(hào)，并說明其不足之處。另外，非常歡迎大家補(bǔ)充分享您的好習(xí)慣。附文：微軟資深軟件工程師：閱讀代碼真的很難為這篇文章評(píng)分窗體頂端窗體底端0 評(píng)論發(fā)表人：關(guān)關(guān)發(fā)表時(shí)間：2011-01-07 11:48 AM編者按：原文作者Eric Lippert是一名資深軟件設(shè)計(jì)工程師，從1996年起一直在微軟開發(fā)部門任職，協(xié)助設(shè)計(jì)并實(shí)現(xiàn)VBScript、JScript、JScript .NET、Windows Script Host、Visual Studio Tools for Office 和 C#。Escalation的工程師JeremyK在他博客中問到：你是怎么教人們快速深入挖掘不熟悉的代碼（不是自己所寫的）？我學(xué)習(xí)如何編程的方法很傳統(tǒng) 自己動(dòng)手編碼。但我現(xiàn)在很糾結(jié)：到底是集中精神閱讀源碼，還是自己編寫。對(duì)我而言，似乎唯一有效的方法就是自己寫過。不是和Jeremy開玩笑，寫代碼的確沒有讀代碼難。首先，我同意你的看法，幾乎很少有人能讀代碼但不會(huì)寫代碼。這不像自然書面語或口語，理解他人的意思并不需要去理解他們?yōu)槭裁匆菢诱f。比如，如果我說：“寫代碼有兩種方式：一種嚴(yán)格且詳細(xì)，另一種模糊且草率。前者生成簡潔分層的婚禮蛋糕，后者卻是意大利面條。”上面這句話產(chǎn)生一個(gè)平衡且幽默的效果，但即使聽眾和讀者不理解我使用“零照應(yīng)”和“并列句”這樣的文字技巧，也會(huì)理解我要說的意思。但是說到代碼，既要從代碼本身中理解代碼作者的意圖，又要理解代碼產(chǎn)生的預(yù)計(jì)效果，這兩者都極為重要。因此，我又回到那個(gè)問題了，有些人需要快速切入代碼，但不需要?jiǎng)邮謱懘a，那我們?nèi)绾尉帉戇m合這些人的代碼？下面是我在編寫代碼時(shí)，盡力去做的事，目的就是使其他人能輕松閱讀： 使代碼遵從工具。Object Browsers和Intellisense雖然很好，但我告訴你，我是守舊派。如果找不到我想要的，我會(huì)不高興。什么使得代碼成為可查詢的呢? 像i這樣的變量名不好。如果沒有明確的錯(cuò)誤提示，你就無法輕易查找代碼。 避免使用是其他名字前綴的名字。比如，在代碼中有個(gè)“perfExecuteManifest”，如果再有一個(gè)“perfExecuteManifestInitialize”，這就會(huì)讓我抓狂，因?yàn)槊看卧谠创a中查詢前者時(shí)，我不得不費(fèi)力地過濾掉后者所有的實(shí)例。 “臨時(shí)傳遞數(shù)據(jù)”（tramp data）應(yīng)使用相同的名字。所謂“臨時(shí)傳遞數(shù)據(jù)”（tramp data），就是指那些傳遞給方法A的變量，還要傳給方法B的變量。這兩類變量實(shí)際上是相同的，所以如果它們有著相同的名字，則更好。 別用宏來重命名東西。如果有個(gè)方法叫g(shù)et_MousePosition，那別這樣GETTER(MousePosition)來聲明該方法。因?yàn)槲視?huì)找不到實(shí)際的方法名。 Shadowing會(huì)引起很多問題，請(qǐng)不要用它。 堅(jiān)持使用一種命名模式。如果你打算用匈牙利命名法，那就堅(jiān)持并廣泛使用，否則將適得其反。使用匈牙利命名法來記錄數(shù)據(jù)，而不是存儲(chǔ)類型；記錄普遍事實(shí)，而不是臨時(shí)條件。 使用斷言來記錄先決條件（preconditions）和后置條件（postconditions）。 別縮寫英文單詞。確切來說，別縮寫成稀奇古怪的形式。在腳本引擎中，有個(gè)變量名叫“NME”，這讓我非常抓狂！它應(yīng)當(dāng)叫“VariableName”。 C語言標(biāo)準(zhǔn)運(yùn)行時(shí)庫的設(shè)計(jì)不是很優(yōu)秀。別去效仿它。 別寫“聰明”的代碼；當(dāng)代碼出現(xiàn)問題，維護(hù)代碼的程序員沒時(shí)間去理解你的聰慧。（編注：這條建議即為：編寫可維護(hù)的代碼，詳情可參見明星軟件工程師的10種特質(zhì)中的第8點(diǎn)。） 理解編程語言特性的設(shè)計(jì)初衷，使用這些特性去做它們適合完成的工作，而不是它們能做到的工作。例如：別把異常當(dāng)做一般的流控制機(jī)制來使用（即便你能做到），而應(yīng)該用它們來報(bào)告錯(cuò)誤。別強(qiáng)制把接口指針轉(zhuǎn)換成類指針，即便你知道這樣沒問題。 按功能單元?jiǎng)澐衷创a樹，而不是按組織結(jié)構(gòu)。比如：我目前所在團(tuán)隊(duì)中，有2個(gè)根子目錄的名字是“Frameworks”和“Integration”，這是兩個(gè)團(tuán)隊(duì)的名字。不巧的是，F(xiàn)rameworks團(tuán)隊(duì)名下有一個(gè)叫“Adaptor”的子目錄，而“Adaptor”卻是Integration的子目錄，這就非常令人迷惑。同理，（如果）有著相同子目錄的不同的子樹，有些是客戶端的組件，有些是服務(wù)端的組件；有些是管理組件，有些是非管理組件；有些是處理型組件，有些是非處理型組件；有些是零售組件，有些內(nèi)部測(cè)試工具。這就會(huì)亂七八糟的。當(dāng)然，我實(shí)際上根本沒有回答Jeremy的問題如何調(diào)試不是我寫的代碼？這取決于我的目的。如果我只是因?yàn)橐粋€(gè)bug，而深挖一段具體的代碼，我會(huì)在調(diào)試器中逐步跟蹤所有代碼，寫下我“走過”的調(diào)用分支，記錄下哪些方法是特定數(shù)據(jù)結(jié)構(gòu)的“生產(chǎn)者”，哪些方法是“消費(fèi)者”；我也會(huì)仔細(xì)盯著輸出窗口，查看出現(xiàn)的有用信息；還要打開異常