???????? 最近在做一個汽車銷售系統的改善工作， 這個系統已經運行兩年了， 兩年來， 客戶不斷的提出新需求， 系統也在不斷的改來改去。 這次輪到我來改它了。 ? 想想 N 年前初學編程的時候， 書上， 網上， 雜志上不斷的在說， 要養成良好的編程習慣。 然后還給出了 N 長的一大篇文章來介紹一些編程規范。 我這個人是很懶的， 大概的看了一下就過去了。 沒有特意的記什么。 好在我這個人也不是特別的懶， 對自己的工作也是很上心。 編程的時候盡可能做到更好。 性能功能能考慮到的都要做到最好。 ? 慢慢的也養成了一些編程的習慣， ? 時間長了， 下意識的就去遵守一些模式，模范之類的東西了。
???????? 有了這些習慣， 再看這次修改的系統， 真的是生可忍熟不可忍了。 ? 這次我也不說什么編程規范了， 我就說說這些編程惡習 。

???????? 一， ? 程序沒有注釋
?????? 注釋 !! 注釋 !!! 如果只是打印了一個 HELLO WORLD ， 您不注釋那也就算了， 如果是只有一兩百行的小功能類您不注釋， 那我也忍了， 可是 3000 多行一個類的業務邏輯代碼， 您老人家還不注釋 !!!?? 你 TM 讓我怎么去改代碼， ? 一點業務邏輯的說明都沒有， 我改代碼的時候，得一邊用 DEBUG 調試， 一邊替他加注釋。 然后才能進行自己的工作。 幾千行的一個類， ? 一行注釋都沒有， 你 TM 就不覺得顏色單調了點嗎 ?

?????? 二， ? 不遵守基本的編程約定
?????? 變量名大小寫混亂， 明明是變量， 非要完全大寫， 要不就大寫開頭。 要不就是方法名全是大寫， 最牛 B 的一個方法是用中文做方法名， 你丫這時候想起打中文來了， 累不累呀。

?????? 還有人用拼音做變量名方法名，就算您英文不好，稍微查一下金山詞霸行不行，現在百度和 GOOGLE 都有翻譯功能，稍微查一下英文，也當是學英語了行不行？ 您實在太忙的話，不查也就算了，拼音就拼音吧，好賴也算是中國話的。 可是您就別用拼音簡寫了，英文簡寫還認不出來呢， 您還用拼音的開頭字母當變量名， 那我 TM 上哪兒猜去呀！

?

?????? 三， 不明就里的代碼

?????? 系統中經常會出現這樣的代碼，尤其是在 controller 里居多：

?????? // some code

?????? If(flag .equals(“submit”)){

?????? model.getInfo();

}else{

?????? model.getInfo();

}

我沒寫錯， if 和 else 調用的方法完全一樣，大家也放心，我仔細的看過調用的代碼，調用的方法里，也沒有根據其它情況來改變他的運行路線。我就不明白為什么要做這個 if 判斷了。擔心會有什么特殊的業務邏輯， 所以也不趕隨便去改他。 猜了半天，感覺最理想的答案是寫代碼的人，擔心以后會有新的邏輯分支， 所以在這里用 if 預留了一個位置， 以后改的時候方便。

數日之后有幸遇見了當初寫這代碼的老兄，問過之后立刻暈倒，原來是這個代碼是參照別的模塊的樣子寫的，別的模塊在這里都有 N 個程序分支，通過 if 來判斷后決定調用哪個 model 里的方法。但他這個模塊很簡單，沒有什么分支，就是調用那一個方法，但他寫代碼時，看別人的模塊在這里都進行 if 判斷了，所以覺得自己也應該判斷一下，于是就出現了上面這樣的代碼。

?

四， 面向過程式的編程方法

遇到過好幾次 2000 多行的方法，所有業務邏輯，一氣呵成，就用了一個方法搞定。如果是簡單的邏輯也就算了， 可是幾千行的代碼全放在一個方法里，一個類里有無數的重復代碼。 這回到好，重構那本書沒白看， 現在有了實踐的機會了。

難道您自己調試的時候就不覺得麻煩嗎？ 我在這里不想討論什么面向過程還是面向對象，也別和我說什么方法多了也不一定就是面向對象的思想。 平時對自己寫的代碼多上點心， 大家都是在這行干了幾年的人了，把代碼寫的漂亮點有什么不好。

?

五， 代碼縮進混亂

我們公司有規定，改代碼的時候，不許修改原有代碼的格式。 不管他多亂，也不許改。 我不明白這是為什么，也許是檢查代碼的人，要用文件比較工具吧。

但這下苦壞我了， 代碼的格式那叫一個亂。 有頂著行頭寫的， 有向后空了 N 格的，大概是寫代碼的人， 為了方便自己找到正在調試的那段代碼，所以把代碼的縮進變得和其它代碼與眾不同吧。 那您調試完了到是重新排一下版呀， 這真的不累～～， 現在的 IDE 工具都有自動排版代碼的功能， 一個快捷鍵就搞定了，稍微勤快一點行嗎？？

最 BT 的一段代碼是縮進居然出了屏幕！！！ 你吃飽了撐的呀， 沒事縮那么遠干嗎， 我根據后臺輸出找了半天也沒找到那段代碼在哪兒， 原來是因為縮進的太遠了，不在屏幕范圍之內， 向右拉了半天滾動條才找到。 你丫是不是寫著代碼睡著了？ 臉正好砸在 TAB 鍵上。

?

六， 多余的后臺輸出

好幾個循環嵌套在一起～～～ 也行， 就算是因為業務邏輯需要，沒別的辦法也將就了。 好幾個循環嵌套在一起查數據庫， 咱們最好還是開動一下腦筋， 看看有什么更好的辦法。如果還是沒別的辦法， 那也湊合了。 可這種情況您就別在后臺輸出 SQL 語句啦， 每次一執行程序，成百上千個 SQL 語句在后臺輸出， 查數據庫才用了一兩秒，結果輸出這些 SQL 就用了半分鐘。 您自己就沒覺出程序慢在哪里嗎？ 您調試程序的時候輸出一下也就算了， 提交到正式運行的環境時，就麻煩您，勞您大駕～～ 把那些輸出注釋掉吧，實在不行留幾個重要的輸出就行了。 讓這種代碼影響系統性能～～ 也太冤了吧。

?

七， 打腫臉充胖子

我也不知道這條算不算惡習，也許不算，在有些人眼里還是好事。但也要看具體情況，經常有些人寫代碼不喜歡用 IDE ，只用 EDITPLUS 這類工具。按常理說，初學者都應該盡量用這些編輯器寫代碼，對加深學習印象有好處。也有人說高手不屑于用那些 IDE ，我少見多怪， 這種絕頂高手我沒見過。

但咱平時工作的時候，要的是效率，您不是那種高手就乖乖的用 IDE 吧。經常見到有些人，為查一個方法的調用，搜來搜去的。真正的高手是工作效率最高的人，不是用最簡單工具的人。

??? 今天就寫這么多， 大家還遇到過什么樣的編程惡習，歡迎補充。

大家不要總是抱怨什么工資太少，工作量太大。工作效率這玩意兒是要經驗來做基礎，這沒錯，經驗少也沒事。咱平時寫程序的時候多上點心，多對自己的代碼思考一下，多動動腦子。自然就能總結出最好的工作經驗了，工作效率自然就提高了。

也別總是說什么 STRUTS 不好， HIBERNATE 太慢，不屑去用它。人家的程序能在全世界流行，自然有他的過人之處。多讀讀他的代碼，學習一下他到底好在哪里，如何才能把這些優點應用到自己的代碼上。這才是最重要的。

?也許咱們寫不出什么高超的代碼技巧，寫不出什么華麗的算法，但如果能在一些習慣，細節上做到精益求精，那也對得起自己的代碼了。


??? 寫出上面這些代碼的人，如果你的工資真的很少，那我只能惋惜的說一句：你的工資是可憐了點，但看您寫的這代碼，連這點工資都不應該給你！！