[[131972]]

本文列出的 10 個錯誤，并不局限于C＃，Delphi，JavaScript 等——幾乎涵蓋了所有的編程語言。是不是大吹大擂，歡迎各位品鑒……

1. 面向編譯器寫代碼，而不是面向用戶

當人們使用編譯器創建自己的 app 時，在把自己的想法訴諸于機器代碼的過程中，常常會將那些可以使得編程更為簡單卻又冗長的語法遺忘于腦后。

無論你使用的是單字母的標識符還是更易于人腦理解的標識符，對于編譯器而言，毫無區別。編譯器不在乎你寫的是否是優化表達式，也不在乎你是否用括號封裝了子表達式。編譯器要做的就是將這些人腦可讀的代碼，解析為抽象的語法樹，并將這些樹轉換成機器代碼，或某種中間語言。

那么，為什么不使用更可讀或者語義更明顯的標識符呢——而不要僅僅是I，J或x。老實說，現在我們用來等待編譯器完成轉換標識符的時間幾乎是微不足道。但是，這么做卻可以大大減少你和其他程序員用于閱讀理解這些源代碼所用的時間。

還有一個類似的觀點是：或許你可能已經記住了相關的運算符優先級，于是省略了表達式中一些不必要的括號，但是卻沒有考慮到后面的程序員有可能會誤讀你的代碼，并就它是如何工作的作出一些無效的假設。

我的想法是，假設大家都知道，乘法（或除法）優先于加法和減法。其他任何我放到表達式中的內容我都會用上括號，以確保能真正表達我的意思，其他人也能真正理解我的想法。

有研究表明，有的代碼維護所需要的時間甚至超出其編寫時間的五倍以上。所以將代碼寫得易于閱讀和理解是非常有意義的。

2. 函數方法過于龐大

有一個經驗法則就是，我們寫的程序不應該過于龐大。而且我們也可以發現，現在方法趨向于越來越小巧——有時候僅僅只是幾行代碼。

從本質上說，要想快速把握程序的目的和意義，只需要一定的代碼就夠了。長方法不但令人難以接受，而且往往最終趨向于支離破碎。

其原因也非常簡單：長方法既難以理解，又難以維護，甚至還難以正常測試。

有一個相當不錯的測量方法可以衡量你的代碼的復雜程度，以及出現 bug 的概率—— 循環復雜度。

該方法由 Thomas J. McCabe Sr 于 1976 年開發。循環復雜度使用方便簡單，能讓你在匆忙之中盡可能地保證代碼運行正常。只需要數一數代碼中‘if’語句和循環的數量，再加1，就是該方法的 CC 值。

當然這只是對代碼執行路徑數量的粗略計數。不過，如果你的某個方法其循環復雜度值大于 10，我建議你重寫。

3. 過早的優化

這一點非常簡單。當我們在編寫代碼的時候，有時我們會自作聰明地對某些代碼過于注重細節過于精益求精，雖然看上去這些“明智”的代碼比原先寫的那些提高了速度，但是你忽略了一個事實，這些“明智”的代碼往往是難以閱讀難以理解的——而且真正節省的時間往往只有幾毫秒。這就是所謂的過早的優化。

著名的計算機科學家 Donald Knuth 曾經說過，“過早的優化是一切罪惡的根源”。

換言之就是：我們的代碼需要清晰、干凈，然后再重點找出真正的瓶頸并對其進行優化。千萬不要試圖過早的優化。

4. 使用全局變量

話說回來，有的編程語言是完全沒有局部變量這個概念的，所以不得不使用全局變量。關于全局變量，雖然我們可以在子函數中使用它，但是卻沒辦法聲明這一變量只能在該函數中使用。盡管如此，全局變量依然非常受歡迎，因為我們只需聲明一次，即可到處使用，太省時省力了有木有。

但是它的優點也是它的缺陷，這也是關于全局變量最糟糕的事情——我們沒有辦法控制它的改變，也沒辦法控制何時去訪問變量。假設某個全局變量在調用到程序之前賦予了一個特定的值，但是很可能調用完了之后值就變了，而你卻毫無察覺。

5. 不進行評估

你的目標是寫一個應用程序，你斗志昂揚，愈戰愈勇。但是突然間，你發現了性能問題和內存不足的問題。

進一步的調查表明，盡管你的設計對于現在這樣小型的用戶數量、記錄、條目運行良好，但是卻不適合大規模的情況——Twitter 就是例子。又或者它現在在你的 8GB RAM 和 SSD 的 3GHz PC 上運行順暢，但一旦到普通的 PC 上，它會比烏龜爬還要慢吞吞。

所以，部分設計進程還是需要評估，需要一系列的封底計算。有多少用戶需要同時處理多少個用戶？需要處理多少記錄？目標響應時間又是多少？等等。

盡量對這些類型的問題進行評估，這樣就可以對應用程序中的一些技術問題做一些更進一步的決策，如不同的算法和緩存。不要什么亂七八糟的都納入到開發中去——你還需要好好評估目標和目的。

6. 大小差一錯誤（數組邊界溢出）

這個錯誤基本上每一個程序員都犯過，通常在寫循環的時候，由于循環變量的步長增加過多或過少，導致循環遍歷元素的次數發生錯誤，產生數組溢出的異常。

這個錯誤會導致遍歷數組元素時訪問不存在的元素，或者遺漏應該遍歷的元素。產生這個錯誤的原因就是你忘記了數組下標是從 0 開始還是從 1 開始了。

7. 淹沒異常

現在的編程語言大多使用異常系統作為錯誤報告技術，而不再是以往傳統的傳遞和檢查故障代碼。現在的編程語言使用新的關鍵字來處理和捕獲異常，其名稱為 throw、try、finally 和 catch 等。

關于異常處理值得一提的是，它們的作用是展開堆棧，從嵌套程序自動返回，直到異常被捕獲并處理。不再需要你檢查錯誤條件，從而導致代碼深陷錯誤測試的泥沼。

通過正確地運用異常處理，我們能夠使得軟件更為強大。比如說 catch 能讓我們捕獲異常，并根據異常類型執行某種行為。

關于異常處理，程序員犯的最大的錯誤有兩種。第一種是程序員對于他們 catch 的異常了解得不夠清楚具體。捕獲過于籠統化的異常類型可能會導致你在不經意間處理掉一些最好能夠保留的特定異常。而這樣做，可能會導致這些異常被淹沒，丟失。

第二個錯誤更為有害：程序員不想要任何異常離開自己的代碼，因此捕獲之后忽略了它們。這就是所謂的空 catch 塊。他們可能是這樣想的，只要 throw 某些類型的異常就可以了：于是名正言順地忽略了這些異常。

而現實是，這可能會導致其他致命的運行時異常——如內存不足的異常，代碼無效的異常等等，從而使得程序無法正常運行。因此，調整異常 catch 塊時應盡可能的具體化。

8. 純文本格式存儲密碼

數據安全性是永遠值得探討的話題，其重要性是不言而喻的。在這里，我要鄭重告訴你的是，千萬不要將密碼用純文本格式保存。

密碼的標準是，先存儲經過加密后雜亂無章的原始密碼，然后再輸入通過相同加密方法后的雜亂的密碼，看看它們是否匹配。

還不清楚這樣做的害處，那么給你個提示：如果某個網站承諾，如果你忘記了原始密碼，他們會給你發送電子郵件告訴你，那么遠離這種網站。這可能會出現巨大的安全問題。假設有一天，該網站會被黑的話，那么你所有的登錄信息都會被泄漏出去，而你除了忍氣吞聲惶惶而不可終日卻毫無辦法。所以，千萬不要接觸這類網站，同樣的，也不要在你的 app 里用純文本的格式存儲密碼或其他的“秘密”。

9. 不驗證用戶輸入

以前的程序是單用戶的，于是我們對用戶輸入往往不以為然：畢竟，如果程序崩潰的話，只會影響到一個人的使用。我們的輸入驗證僅限于數值驗證、日期檢查，或其他類型的輸入驗證。

文本輸入往往不會特別驗證。不過后來出現了網頁。于是，你的程序有了遍布世界的用戶。而一些惡意用戶則會通過輸入數據到你的程序，以試圖接管你的 app 和服務器。

新型的攻擊大多是因為缺乏對用戶輸入的檢查。其中最著名的是 SQL 注入，通過標記注入，不好的用戶輸入可能會引發 XSS 攻擊（跨站腳本）。

這兩種類型都依賴于用戶提供包含了 SQL 或者 HTML 片段的文本，來作為正常表單輸入的一部分。如果應用程序不驗證用戶輸入，直接就拿來用，那么很可能就會執行篡改的 SQL，或者產生一些被攻擊的 HTML/JavaScript。

這反過來可能會使得 app 崩潰，或被黑客接管。為了避免這些情況，所以我們應該時時驗證或消除用戶輸入。

10. 不與時俱進

上述這些我總結的內容或許并不新鮮——你可能已經在其他的書籍或網頁上涉獵過。但是隨著時代的發展，會有越來越多的新的設計和編程技術面世。

而你如果還抱著一些陳舊的逐漸在被淘汰的技術不放，不愿意學習和了解新的編程方法和技術——那么你終將會被拍死在沙灘上。對于程序員，學習是永恒的課題。例如 TDD 和 BDD，SLAP 和 SOLID 方法，以及各種敏捷技術，都是我們應該學習的技術。

我們應該時刻保持對最新的編程藝術和實踐的同步。