程序總出故障，這10個容易犯的編程錯誤你避免了嗎？
譯文【51CTO.com快譯】為什么程序出故障？雖然自世界上第一位女程序員艾達·洛夫萊斯（Ada Lovelace）在上世紀(jì)第一次看到通用計算的潛力以來我們已取得了很大進展，但是我們編寫的軟件還是錯誤百出。這些年來，盡管我們開發(fā)出許多高級方法來確保代碼的成功，但是程序還是不斷的出故障。
原因何在？
雖然這個問題的答案多種多樣，但我們還是決定提供一個務(wù)實的答案。程序員難免犯錯。他們有時馬虎了事。他們并不總是使用最佳工具或最佳實踐。
我在加州大學(xué)伯克利分校教面向?qū)ο缶幊踢@門課，我在學(xué)校教優(yōu)秀編程實踐所花的時間與幫助學(xué)生理解代碼本身所花的時間相比只多不少。我在課堂上看到許多常犯的錯誤，本文就介紹其中幾個常見錯誤。
我還聯(lián)系上了西北理工大學(xué)工程學(xué)院的詹姆斯·A·康納（James A. Connor）教授，請他介紹其學(xué)生常犯的一些錯誤。
我先來說幾個。
第一個錯誤：糟糕的注釋方法。
注釋是程序里面計算機并不執(zhí)行的那部分文本。它們被程序員寫成附注的形式，用來解釋代碼里面發(fā)生的情況。
我的好多學(xué)生避免給代碼添加注釋，也想不明白為何要占用實際編碼的時間去編寫一些注釋。我最實用的例子來自我自己的生活。
早在世紀(jì)之交前，我編寫了版本1.0的ZENPRESS，這是最古老的內(nèi)容管理系統(tǒng)之一。我預(yù)計它會帶來好幾年的文章。14年過后，它仍在管理許多文章，準(zhǔn)備好了75000篇文章和26億頁的內(nèi)容。
最后，它運行所依賴的那個平臺過時了。我不得不回過頭去研究代碼。2009年，我把代碼從原始平臺移植到現(xiàn)代平臺。我最近不得不再次改動，因為PHP一個關(guān)鍵的語言特性在版本升級后完全消失了。
19年過后，我根本記不起所有這些代碼是怎么運行的，但是由于我對代碼作了詳細(xì)的注釋，所以可以說有了一份路線圖。我可以查看代碼，查看嵌入在代碼里面的注釋，然后進行修改。
你在團隊工作時，或者你的軟件不歸你監(jiān)管時，注釋也很重要。你的職業(yè)生涯可能發(fā)生變化，別人可能需要過來了解你的代碼。注釋將大有幫助。
第二個錯誤：糟糕的變量命名。
我會繼續(xù)探討這個主題：通過語言讓代碼一目了然。我會用一個例子來表明這點。假設(shè)你駕駛一輛每加侖汽油跑20英里的汽車，開了100英里。請問你用掉了多少汽油？
這是個簡單的例子，但是適用于我們的用途。假設(shè)你遇到了a = b/c這一行。a指什么？b和c又指什么？它們與你的其余代碼有何關(guān)系？在編寫程序十分鐘后，你會記得一干二凈。更不用說別人過來修改代碼或編寫更新版了。
現(xiàn)在看看這個表達式：加侖 = 英里/每加侖行駛英里數(shù)。每一個變量的具體用途就一目了然。一個代表加侖，一個代表英里，另一個代表每加侖行駛英里數(shù)。很清楚。
想一想為變量賦予清楚的英語（或者其他任何母語）名稱與注釋之間的關(guān)系。假設(shè)你從別人那里接過了一段代碼，看到a = b/c。這代碼用來干嘛？你有何頭緒嗎？
務(wù)必以一種代表其功能的方式來命名變量。那樣可以節(jié)省大量的時間，減少許多頭痛的問題。
第三個錯誤：沒有實驗筆記（lab notes）。
我在1997年年中開始編寫ZENPRESS，它在1998年1月份上線。遺憾的是，我當(dāng)時匆忙完成了項目，沒有花時間為這第一個版本編寫實驗筆記。此后我懊悔多次。從1999年6月份開始（當(dāng)時我開始編寫版本2），我就經(jīng)常做實驗筆記了。
實驗筆記是代碼注釋之外的記錄?？茖W(xué)家一直在使用實驗筆記，作為其研發(fā)過程的日志或?qū)υ拑?nèi)容。實驗筆記用來證明科學(xué)發(fā)現(xiàn)歸誰所有，因為研究過程常常記錄在科學(xué)家用來記錄進度的每天日志中。
實驗筆記對程序員來說同樣是一種有效的工具。我為ZENPRESS編寫的上一份實驗筆記是在今年3月份編寫的，當(dāng)時我不得不把ZATZ歸檔從一家主機托管提供商遷移到另一家。我還經(jīng)常對自己的其他項目做實驗筆記，由于能夠回過頭去查閱筆記，好多次幫了大忙。
如果你還沒有做實驗筆記，現(xiàn)在就開始做。記下你做的任何變化，你的理由，你考慮后丟棄的代碼，參考的實用資源，以及將來幫助你的任何其他內(nèi)容。你還能幫助將來的同事或接手人――如果你需要證明歸屬權(quán)，實驗筆記還能起到證明的作用。
第四個錯誤：不用一種人類語言編寫。
我的學(xué)生要考試過關(guān)，不僅僅要編程，他們還要編寫討論區(qū)帖子，證明他們熟知某些編程概念。
我們提出這個要求出于兩個原因。當(dāng)然，首先是為了證明熟悉概念。但是更為重要的是需要所有專業(yè)人員都有編寫能力。
我在這方面遭到學(xué)生們的反對。每學(xué)期都有學(xué)生高喊：“我想成為程序員，而不是編寫者。”但是編程、工程、IT和幾乎所有專業(yè)工作都不可能在真空狀態(tài)下存在。
你需要通過編寫來解釋概念、推銷想法、獲得資金、要求澄清、準(zhǔn)備提議，或者甚至為拿到更好的分?jǐn)?shù)據(jù)理力爭。開源項目的參與者在非常龐大的團隊協(xié)同工作，他們保持同步的唯一手段就是編寫清楚的、易于理解的信息。
結(jié)論很簡單：如果你想要從事專業(yè)工作或從事任何重要的項目，就需要用一種人類語言（比如英語）來編寫，而不僅僅是用一種編程語言來編寫。
第五個錯誤：糟糕的代碼格式。
毫無疑問，這里的一個主題就是：讓代碼易于了解。代碼維護起來極耗費時間和財力。坦率地說，這也不是很有趣。最好還是能夠把寶貴的工作時間用來添加功能，而不是花幾周來鉆研舊代碼，試圖搞清楚你（或者交給你代碼的那個人）想要完成什么任務(wù)。
本人就遇到過這種事，不僅僅是來自我的舊代碼，還來自從別人手里接過的代碼。我接手被丟棄的WordPress 開源插件作為一個副帶項目。據(jù)我所知，我接手的插件比其他任何人都要多。每個插件都是由別人開發(fā)的，為了保持插件可以正常使用，我不得不鉆研陌生人的代碼。
幸好，那些開發(fā)人員都是高手，深諳編程之道。要不然，我也就無法接手這些項目了。但即便如此，要盡快上手還是困難重重。你能想象要是他們編寫的代碼結(jié)構(gòu)很糟糕，那會有多難嗎？
我所說的結(jié)構(gòu)是指代碼的布局方式。我為學(xué)生制作了這方面的一段視頻。有興趣的話，大家可以上YouTube觀看（https://youtu.be/0u-I016Hxlw）。
想一想你在網(wǎng)上讀到的文章。一些文章格式優(yōu)美，每一個段落之間有一行，一切都保持一致?？墒怯行┪恼露加靡粋€大大的blob來排列，沒法看清。
每個程序員（或項目）都往往有一種編程風(fēng)格。你的風(fēng)格是什么樣不是同樣重要，只要保持一致就行。你需要讓代碼格式來幫助引導(dǎo)。
比如說，在我的代碼中，我堅持代碼段之間的空行不得超過一行。如果我看到一段更大的空白區(qū)，我立即就知道這一點：哪里出現(xiàn)了異常，這個空白區(qū)里面可能有錯誤。
你在深入研究代碼時，要關(guān)注貴企業(yè)有沒有編程風(fēng)格?？紤]為你的所有程序員定義一種編程風(fēng)格，堅持采用清楚、易于維護的那一種風(fēng)格。
第六個錯誤：糟糕的錯誤檢查。
某位著名的將軍曾經(jīng)說過，遇到敵人時，計劃根本不管用。我在此基礎(chǔ)上改動一下，遇到用戶時，你的代碼根本不管用。盡管你認(rèn)為自己知道用戶會如何使用代碼，但你其實并不知道，相信我。
用戶會搞壞你的代碼。
正確的處理方式就是借助測試和錯誤檢查。錯誤檢查是指這種做法：檢查代碼中每一次操作的結(jié)果。確保它符合你的預(yù)期，或者確保你的代碼可處理意外的結(jié)果。
比如說，我的學(xué)生經(jīng)常有一項任務(wù)：閱讀文件。幾乎所有的學(xué)生編寫代碼時會調(diào)用文件讀取例程。他們檢查用戶是否取消對話框，但是很少查看文件是否實際上被讀入，或者是否存在某種類型的系統(tǒng)錯誤。要是他們試圖編寫文件，那就更糟糕了。他們幾乎從不真正查看文件是不是實際上保存起來。真是要命。
不難發(fā)現(xiàn)這會有多糟糕。為了對付這種情形，你總是要考慮能不能絕對預(yù)測行為，然后認(rèn)識到你不能絕對預(yù)測行為。你需要測試。測試并不是僅僅指你自己運行代碼。測試意味著讓實際用戶（即行為可能無法預(yù)測的那些人）運行你的代碼。
你會發(fā)現(xiàn)這會提供大量的信息。
第七個錯誤：使用打印輸出語句，而不是真正的調(diào)試器。
這些年來我發(fā)現(xiàn)，使用不同語言的程序員往往有不同的文化。總的來說，那是由于他們構(gòu)建不同種類的解決方案、使用不同的工具。
這方面的一個例子就是我的C#編程學(xué)生和與我一起開發(fā)一些項目的開源PHP開發(fā)人員之間的區(qū)別。幾乎沒有一個C#程序員會考慮不使用一種符號調(diào)試器來調(diào)試代碼。那是由于， C#本身是使用Visual Studio作為編程環(huán)境來編寫的，調(diào)試器內(nèi)置在里面。
相比之下，我見到許多PHP開發(fā)人員認(rèn)為只要插入echo語句或var_dump就足以幫助自己調(diào)試代碼了。這一方面是由于，大多數(shù)PHP程序員往往在編輯器里面編程，而不是在開發(fā)環(huán)境里面編程。兩者之間的一大區(qū)別就是調(diào)試器。
那么，調(diào)試器是什么東東？簡而言之，這種工具讓你可以在代碼運行時查看代碼內(nèi)部的情況。它就好比是代碼的X光、超聲波或MRI?？梢灾噶钫{(diào)試器在某些點停止，檢查所有變量的狀態(tài)。還可以指令調(diào)試器在某些條件下停止。你可以更改值，可以查看和分析值（不過分析有時是另一種工具）。
工作效率方面的差異很大。如果你想更快速、極其準(zhǔn)確地完成工作，就要確保使用一種真正的符號調(diào)試器。
以上就是我所介紹的幾個常見錯誤，下面看看詹姆斯·康納教授介紹的幾個。
第八個錯誤：使用魔數(shù)（magical number）。
許多程序員認(rèn)為，他們只要編寫一次代碼，代碼就能完美無缺。然而，為了優(yōu)化企業(yè)軟件和工業(yè)軟件的長期生命周期成本，有必要編寫能夠抵御不斷變化的條件的代碼。
這方面的一個典例就是魔數(shù)這個想法。我所說的魔數(shù)是指程序員認(rèn)為總能經(jīng)受得住時間考驗的數(shù)字。
以可能基于客戶的采購數(shù)量的傭金計算為例。截至截稿時，傭金比例可能是三個百分點，即0.03。
現(xiàn)在，設(shè)想一下會如何編寫這段代碼：傭金= .03 *銷售額。在這個上下文中，這個魔數(shù)就是0.03。由于程序員認(rèn)為這會是永遠神奇地有效，他將0.03這個數(shù)字硬編碼到代碼中。
這一切很好，但是每年的傭金往往發(fā)生變化。如果下一年傭金漲了0.5%，漲到0.035，那么就很難在成千上萬行代碼中找到它。
切忌使用魔數(shù)，而是在一個地方定義變量或常量，讓代碼使用那些變量。如果你預(yù)先定義commission_rate，那么commission = commission_rate * sale之類的代碼就不需要改動。
要考慮的另一個方面是，無論你在何處找到魔數(shù)，都應(yīng)該找到想要提供給用戶的選項，以便用戶可以在偏好設(shè)置部分可以設(shè)置。
第九個錯誤：馬虎對待的日期和時間。
這里有個難題：一年有幾天？365天也許是平常的回答，但今年當(dāng)然有366天。一天會有365.25天嗎？這不可能。
但我的一些學(xué)生認(rèn)為，既然閏年每四年就出現(xiàn)一次，所以每年平均下來因此是365.25天。在進行日期計算時，他們使用這個平均值；因而，結(jié)果根本不正確。
常常更好的辦法是使用系統(tǒng)庫來計算日期，因為你計算的日期可能不是西方日歷日期。
不妨看一下時間方面的類似問題。每幾年，由于地球轉(zhuǎn)速減慢，有一天會多出一秒來，通常是在6月30日或12月31日那天。這叫作閏秒，因而，時鐘可能從11:59:59走到11:59:60再走到12:00:00。
這是第二個時間挑戰(zhàn)。在使用夏令時的地方，交易的進行有可能亂套。比如說，先置入交易A，但是隨后時間被向后重置1小時，那么就置入交易B。然而，如果你在時間序列方面很馬虎，它就會記錄為交易B先發(fā)生。這種類型的時間錯誤會導(dǎo)致產(chǎn)生不必要的罰款，還會導(dǎo)致其他各種各樣的混亂。
再次，有許多好的語言和系統(tǒng)庫可以處理這兩種時間問題。常常更好的辦法是使用現(xiàn)有的庫，而不是編寫自己的時間計算代碼。
第十個錯誤：沒有選擇合適的數(shù)據(jù)結(jié)構(gòu)。
數(shù)據(jù)結(jié)構(gòu)是表示程序中數(shù)據(jù)的一種機制。許多人聽說過鏈表、樹和數(shù)組之類的術(shù)語。這每一個術(shù)語都是數(shù)據(jù)的邏輯表示，對應(yīng)于你試圖表示的數(shù)據(jù)的一些架構(gòu)結(jié)構(gòu)。
我看到程序員（無論編程高手還是菜鳥）最常犯的錯誤之一就是，很少注意數(shù)據(jù)結(jié)構(gòu)方面的選擇。由于你的幾乎所有代碼都建立在選擇的那種數(shù)據(jù)表示方法上，一旦選錯數(shù)據(jù)結(jié)構(gòu)，會在將來帶來嚴(yán)重的影響。
下面這個例子可以表明這種設(shè)計錯誤：選擇一個簡單的堆?；蜿犃?，而不是循環(huán)隊列。堆棧就好比是一堆盤子。你取下底部盤子，然后放上另一只盤子，再取下另一只盤子，依次類推。
如果你想拿走一只盤子，你從最上面拿走。這就叫后進先出?？蓡栴}，如果你需要拿走早些時候放的東西，就很麻煩了。假設(shè)一堆棧盤子有10只盤子。想找到第一只盤子，你就得先拿走其他所有的盤子。
現(xiàn)在，不妨想象一下隊列。如果你在銀行排隊，就處于隊列中。第一個進去的也是第一個出來的。一旦第一個人得到了服務(wù)，下一個人跟上，然后該人得到服務(wù)。出現(xiàn)的另一種情況是，每個人都向前邁一步，在隊列中向前移動位置。
要是許多人來排隊，會出現(xiàn)什么情況？要么他們被拒之門外，要么隊伍排到門外面。第一個人叫到后，所有這些人都要往前移動。
如果你有大量數(shù)據(jù)，這種隊列就會極其低效。每當(dāng)從隊列的開頭獲取數(shù)據(jù)，所有數(shù)據(jù)都要移動。我們置身于大數(shù)據(jù)時代，有源源不斷的數(shù)據(jù)從我們的系統(tǒng)通過。
在這種環(huán)境下，一種更好的辦法也許是實施循環(huán)隊列。在這種情況下，數(shù)據(jù)根本不動。相反，設(shè)置的指針指向隊列的開頭和末尾；在內(nèi)部，隊列首尾相連，那樣數(shù)據(jù)以圓環(huán)、而不是隊列的方式來加以組織。當(dāng)數(shù)據(jù)元素使用、從圓環(huán)中移除后，就不需要移動圓環(huán)中的所有數(shù)據(jù)。發(fā)生的只是第一個元素的指針指向圓環(huán)中的新元素。
有許多例子可以表明選擇正確的數(shù)據(jù)結(jié)構(gòu)會給你代碼的效率帶來重大影響，這僅僅是其中一個。
但愿你在看完本文后，會成為一名更高效的程序員，避免其中一些嚴(yán)重錯誤。
原文標(biāo)題：Software bugs? Avoid these 10 costly programming mistakes，作者：David Gewirtz
【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】
