10個對開發專案有害的程式設計習慣

本文由碼農網 – 小峰原創翻譯，轉載請看清文末的轉載要求，歡迎參與我們的付費投稿計劃！

避免這些常見的編碼習慣，會讓我們的工作更輕鬆、軟體更安全且更易於擴充套件。

帕雷託法則明確指出，20％的因導致80％的果。又稱為80-20法則，它適用於幾乎每一個需要人作為勞動主體的相關領域。

在軟體開發領域，這個法則可以概括為，大多數的問題都是由少數不良編碼習慣造成的。改變這些習慣，你會更有效率。

下面講講最要不得的10條編碼習慣：

1.拼寫錯誤

讓我特別訝異的是，為什麼大家明知這個習慣百害而無一利，竟然還是任其在程式碼中肆虐橫行，以致於經常出現拼寫錯誤的變數名和函式名。更加悲劇的是，錯誤的拼寫常常隱蔽得很好，很難發現。

至於解決方法，可以在一個良好的整合開發環境（IDE）上寫程式碼，或者乾脆用程式設計師專用的文字編輯器，這些都可以顯著減少拼寫錯誤。還可以選擇特定的變數名和函式名，一方面容易拼寫，另一方面即便寫錯了也能輕易發現。儘量避免使用很容易拼錯的單詞，例如“receive”，很容易拼寫成“recieve”。

2.未按規定格式寫程式碼

縮排和格式化，能讓我們的程式碼一目瞭然、易於理解，有什麼錯誤也能一覽無餘。而且也方便別人理解和維護。

如果你使用的是不會自動格式化程式碼的IDE，那麼可以考慮使用程式碼美化軟體，如Uncrustify，這個軟體允許使用者自定義格式要求，然後它會一絲不苟地執行。

3.未按規定模組化編寫程式碼

一個函式對應一個指令的習慣相當好，因為簡短所以易於理解和維護。長函式實現的可能路徑太多，所以測試起來就特別麻煩。

第一個規範原則：一個函式最多隻能佔一螢幕的空間。第二個：如果有10個以上的if語句或者迴圈語句，那麼你就可以考慮重寫了。

4.過度依賴IDE

毫無疑問，IDE和其他一些工具能讓你的程式碼寫得又快又好。在一定範圍內它們能提供變數和其他很多東西，給出你想要輸入內容的多種選擇提示。但是這種型別的工具也存在著風險——如果你不能保證自己有火眼金睛，那麼很容易誤選相似的變數名。從本質上說，這類工具替代了人的一部分思維，但實際上這是你自己的責任。

工具的確是我們的好幫手，例如可以消除拼寫錯誤，以及提高工作效率等，但是如果你自己不仔細的話，同樣會有寫錯程式碼的問題出現。

5.使用硬編碼的密碼

很多人傾向於硬編碼一個祕密帳戶和密碼，這樣之後就可以自由進入系統。但是這是不對的——沒錯，這於你而言的確是大大的方便了，但同時這也大大方便了別人去訪問你的原始碼。

究其原因在於，硬編碼的程式碼比你想象的還要脆弱，這就使得它成為了一個巨大的安全隱患，而且還是一個很不好修復的安全隱患。

6.沒有采取良好的加密手段保護資料

敏感資料在網際網路上傳輸時是需要加密的，因為在這個過程中它很有可能被攔截。不要抱怨麻煩，這是最基本的安全要求。

這也意味著以明文形式傳送資料是不被認可的，同時也排除了我們使用自己的加密方式和混淆目標的措施。寫安全加密系統是很難的——看看wep的情況就知道了——所以我們不妨使用經過驗證的標準加密庫。

7.過早優化程式碼

Donald Knuth，一位傳奇的程式設計師，曾經說過，“程式設計師將太多的時間花在了思考和擔憂程式非緊要部分的進度問題上，因為這些舉措反而對效率產生了強烈的負面影響，如果還同時要考慮到除錯和維護的話，那麼影響更甚。”

善於寫程式碼的程式設計師的確能讓程式碼跑得更快更順暢，但是後期除錯和維護相反則會變難。提供一個好策略：清清楚楚地寫好程式碼之後，再去找真正需要優化的地方以提高效能。

8.沒有超前的思想

專案的目標是什麼？預計規模有多大？會有多少使用者，執行速度得有多快？這些問題乍一看上去好像和我們程式設計師沒啥關係——但是，如果不好好思考這些問題，我們怎麼能正確選擇開發應用程式的框架，以滿足這些要求？

Twitter在這方面就有因為低估未來需求而失敗的例子，導致其最終不得不放棄Ruby on Rails，並且重寫了很多使用Scala和其他技術的程式碼，這是因為原先用於架構的Ruby程式碼，根本跟不上Twitter的快速增長的使用者群。

9.以為增加人手就能加快進度

幾乎所有的軟體專案都會落後於計劃。有人會說，人多力量大，落後了那我新增人手不就能跟上進度了嗎？聽上去挺美的，但事實卻是，幾乎所有的專案在增加“新鮮血液”之後都發生了“凝血反應”——整體效率不升反降。

10.知錯不改，錯上加錯

接上面第9點，有人會說，既然不能新增人手，那我死命趕進度總可以了吧。我奉勸一句，不要抱這種幻想。如果你遠遠落後於計劃時間，那說明本身你對專案的預估時間就是錯的。不要盲目地堅持將錯就錯，還是早點對專案時間做新的估計吧。