很多人錯誤地認為編碼只是熟練手的事情，其實要成為優秀的編碼人員就必須進行自我剖析，拋棄不良的習慣，展示自己優秀的編碼能力。通常不良的編碼習慣有很多種，這裡列出7條編碼者經常會犯的錯誤，提醒大家注意。
（1）自由格式的代碼
如果我們不從一個團隊角度出發，而是從程序員個體角度去看問題：A項目的風格和B項目的風格迥異，甚至是在同一個項目的不同類中風格也不同，不用縮進，不添加註釋，想加接口就加個接口，不想加就不加，我們要的是「自由，自由，還是自由」。——這不是一個成熟的職業者應該具有的，我們應該保持自己的代碼風格，即使它是錯的，也比沒有風格要好。
（2）不使用抽像的代碼
這也算是IDE的便利性造成的習慣，一個業務類不進行抽像，直接進行編碼，在需要修改時，要麼依靠IDE批量重構，要麼通過查找替換的方式重構，很方便，不是嗎？而且，隨著SSH的普及，「無抽像」編程進一步橫行起來。要接口何用？想要修改的時候直接修改XML配置文件就可以了，要什麼接口！系統間數據交互？序列化為XML傳遞，與接口何干？！
這是一種非常拙劣的習慣，抽像的意義不在於編碼，而是在於對業務的理解，接口是對業務宏觀的描述，而不是實現代碼。
（3）彰顯個性的代碼
技術人員追逐最新的技術，這本是無可厚非的，但是新技術只能作為技術的一個方向，不適合立刻投入生產中，要知道一個項目的運行質量是遠遠高於代碼質量的，不要為了一個新穎的API就在生產中嘗試使用，不要做小白鼠。
這裡介紹一個「最小驚詫原則」（Principle Of Least Surprise簡稱POLS，或者Principle Of Least Astonishment簡稱POLA），其意是說要使用最常見的，而不是最新穎的功能。在編碼時，應尋找最常用的方法來實現，比如，同樣有兩個方法都能實現一個算法，選擇那個最常用的，而不是那個別人一看就驚呼「哇哦，算法這麼牛」的，讓普通人都能看懂的代碼才是最簡潔的代碼。
最小驚詫原則也同樣適用於UI設計，當操作界面上兩個元素衝突或重疊時，首選是那個不讓用戶感到吃驚的元素。
（4）死代碼
可能是忘記刪除的代碼，也可能是故意保留的類似「到此一遊」的簽名代碼，這些代碼按照正常的執行邏輯是不可能被執行到，但是在某些未知情況下它就是執行了，此時就會產生嚴重的影響。
（5）冗余代碼
寫了一個實現類，過了N天後又廢棄了，之後這個類就永久地保留下去了，沒人知道它為什麼沒被刪除掉。甚至有時候竟然還能在生產機上尋找到測試程序的身影，它的生命力可謂頑強呀！估計如果有一天將生產機移植到月球上，這段代碼可能還能存在。
曾經遇到過一個項目，項目中建立了單元測試機制，但在生產代碼中還能看到main方法，謂之「測試方便」——刪除它，它不應該在這裡！
（6）拒絕變化的代碼
哲學上說任何事物都是在運動著的，但是我們有些代碼卻不遵循這一個規律，一個在JDK 1.1中就過時的方法還還能在使用JDK 1.6項目中存在，謂之曰「沒有壞，就不要去修它」——該重構它了，它沒壞，但它賴以生存的環境已經變了！
我甚至還遇到過一個新項目還準備使用一個5年前的工具包（此工具包已經經歷了3次大的版本變更），謂之曰「好用，沒有什麼Bug」，但不要忘記了，環境在前進，我們不跟隨就只能落單——不會有人陪著我們找Bug，不會有人去修正，不會有人去做性能優化，我們能做的就是孤軍奮戰了！
（7）自以為是的代碼
這是我們編碼的最大忌諱，認為自己無所不能，編碼不會出現任何錯誤，於是不編寫測試代碼，或者測試代碼只是為了應付質量檢查人員，那等待我們的惡果就是系統上線後徹夜徹夜地修復Bug——自己排除自己埋下的地雷。
自以為是還表現在對產品或工具的選型上，相信自己編寫的工具類，而不是開源工具，寧願自己寫序列化工具，也不選擇kryo或protostuff；寧願自己寫日期處理工具，也不選擇Joda或date4j；寧願自己寫批處理框架，也不選擇Spring Batch，這樣是不行的！——相信天外有天吧，更多更好的工具等待著你去發掘。