在軟體開發領域，很多問題都是由一些不好的程式設計習慣導致的，消滅掉這些壞習慣，讓你的開發更容易，也更有效率。
1. 程式碼中有拼字錯誤
不要驚訝，這是非常常見的問題，最令你抓狂的是這和你的程式設計能力沒有任何關係。儘管如此，一個拼錯了的變數名字或函數名字都會帶來災難性的後果，而且它們還不易被察覺。
那麼如何解決呢？你應該使用一個好的整合開發環境（IDE）或一個程式專用的程式碼編輯器，它們都可以極大程度地幫助你減少拼字錯誤。還有一種方法就是，刻意選那些容易拼的名字當變數和函數名，這樣容易發現錯誤。避免那些容易拼錯的字詞，像receive很容易寫錯成recieve，而且它們很難被發現。
2. 程式碼沒有縮排或格式化
對程式碼進行縮排或統一格式，可以讓人更容易閱讀，也容易對錯誤進行定位。另外，因為是連貫的格式，別人維護你的程式碼也比較方便。
如果你使用的IDE不能自動統一程式碼的格式，可以考慮使用像Uncrustify這樣的程式碼美化器，它能根據你的設定對程式碼進行格式化。
3. 沒有讓程式碼模組化
讓每個函數實現且只實現一個功能，這樣會讓函數更短，相應的就好理解和維護。比較長的函數裡面通常有很多路徑，對測試來說也比較難。
一個好的經驗準則就是一個函數的長度不應該超過你的螢幕。還有就是，如果一個函數裡有超過10個的if語句或循環語句，那它就太複雜了，需要重寫。
4. 你誤以為你的IDE很安全
IDE和其它的一些工具可以提高寫代碼的效率，它們可以根據你已有的輸入和作用域，建議（補全）你的變量名字或其他內容。但是，這類工具是不夠安全的，你會因為一些選項看起
來很想你需要的那個就選了它，其實你並沒有他就是那個你想要的。事實上，它只是減少了你的思考，但你還需要確認。
5. 過早的最佳化程式碼
具有傳奇色彩的程式設計師Donald Knuth曾經說過：「程式設計師花了很多時間在思考那些非關鍵部分的程式碼，這樣的最佳化反而對後續的調試和維護起到了負面作用。一個真正好的策略是：先清楚地寫好你的程式碼，然後如果有一部分程式確實需要優化從而提高效能的話，你再去做這項工作。
6. 沒有事先的規劃
你的專案用來做什麼？你對它的預期規模是多大？有多少用戶會使用它？它可以運行多快？這些問題的答案不是現成和確定的，但如果你對它們進行了錯誤的估計，那你要如何選出一個合適的開發框架，從而滿足需求呢？
7. 增加人手加快進度
幾乎所有的軟體開發專案都落後於計劃，增加專案的人手從理論上來講是可以的，也很不錯。但這其實是常見誤區，事實上，這樣通常都會降低整體的效率。
8. 使用錯誤的時間預期
同樣，不要存在幻想，你可以趕上落後的進度。如果你已經落後於計畫的時間表了，這是由於你預估的時間是錯誤的，這時你應該重新評估整個專案的周期，而不是盲目地堅持那個錯誤的時間規劃。
