如何寫出無法維護的代碼?(3)

　　不要使用{}。不要在if else使用{}，尤其是在你重量地使用if-else嵌套時，你甚至可以在其中亂縮進代碼，這樣一來，就算是最有經驗的程序員也會踩上陷阱。

　　使用宏定義。宏定義絕對是混亂C/C++代碼的最佳利器。參看 老手是這樣教新手編程的。

　　瑣碎的封裝。比較封裝一個bool類，類里面什么都做，就是一個bool.

　　循環。千萬不可用for(int i=0; i

　　測試

　　從不測試。千萬不要測試任何的出錯處理，從來也不檢測系統調用的返回值。

　　永遠不做性能測試。如果不夠快就告訴用戶換一個更快的機器。如果你一做測試，那么就可能會要改你的算法，甚至重設計，重新架構。

　　不要寫測試案例。不要做什么代碼覆蓋率測試，自動化測試。

　　測試是懦夫行為。一個勇敢的程序員是根本不需要這一步的。太多的程序太害怕他們的老板，害怕失去工作，害怕用戶抱怨，甚至被起訴。這種擔心害怕直接影響了生產力。如果你對你的代碼有強大的信心，那還要什么測試呢?真正的程序員是不需要測試自己的代碼的。

　　其它

　　你的老板什么都知道。無論你的老板有多SB，你都要嚴格地遵照他的旨意辦事，這樣一樣，你會學到更多的知識如何寫出無法維護的代碼來的。

　　顛覆Help Desk。你要確保你那滿是bug的程序永遠不要被維護團隊知道。當用戶打電話和寫郵件給你的時候，你就不要理會，就算要理會，讓用戶重做系統或是告訴用戶其帳號有問題，是標準的回答。

　　閉嘴。對于一些像y2k這樣的大bug，你要學會守口如瓶，不要告訴任何人，包括你的親人好友以及公司的同事和管理層，

　　忽悠。你會學會忽悠，就算你的代碼寫得很爛，你也要為其掛上GoF設計模式的標簽，就算你的項目做得再爛，你也要為其掛上敏捷的標簽，只有學會像中國Thoughtworks的咨詢師那樣去忽悠，你才能學會更炫更酷的方法，讓整個團隊和公司，甚至整個業界都開始躁動，這樣才能真正為難維護的代碼鋪平道路。

　　這個文檔中還有很多很多，實在是太TMD強大了，大家自己去看看吧。有精力有能力的朋友不妨把其翻譯成中文。

　　總之，我們的口號是――

　　Write Everywhere, Read Nowhere

原文轉自：http://blogread.cn/it/article/3859?f=wb