转载

Coder 大大，你也犯過這 10 大錯誤嗎？

本文列出的 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 裡用純文本的格式存儲密碼或其他的「秘密」。