前言

上一篇的程序員已經(jīng)祭天了。?，F(xiàn)在換我繼續(xù)，不要慫就是發(fā)。

偽裝

當(dāng)一個bug需要越長的時間才會暴露，它就越難被發(fā)現(xiàn)。
– Roedy Green（本文真·作者）

編寫無法維護(hù)代碼的另一大秘訣就是偽裝的藝術(shù)，即隱藏它或者讓它看起來像其他東西。很多招式有賴于這樣一個事實：編譯器比肉眼或文本編輯器更有分辨能力。下面是一些偽裝的最佳招式。

把代碼偽裝成注釋，反之亦然

下面包括了一些被注釋掉的代碼，但是一眼看去卻像是正常代碼。

如果不是用單綠色標(biāo)出來，你能注意到這三行代碼被注釋掉了么？

用連接符隱藏變量

對于下面的定義

#define local_var xy_z

可以把 “xy_z” 打散到兩行里：

#define local_var xy
_z // local_var OK

這樣全局搜索 xy_z 的操作在這個文件里就一無所獲了。對于 C 預(yù)處理器來說，第一行最后的 “” 表示繼續(xù)拼接下一行的內(nèi)容。

java交流學(xué)習(xí)

其實做為一個java程序員，有一個學(xué)習(xí)的氛圍跟一個交流圈子特別重要，關(guān)注小編，私信發(fā) java ，一起學(xué)習(xí)吧

文檔

任何傻瓜都能說真話，而要把謊編圓則需要相當(dāng)?shù)闹腔邸?/p>
– Samuel Butler (1835 – 1902)

不正確的文檔往往比沒有文檔還糟糕。
– Bertrand Meyer

既然計算機(jī)是忽略注釋和文檔的，你就可以在里邊堂而皇之地編織彌天大謊，讓可憐的維護(hù)代碼的程序員徹底迷失。

在注釋中撒謊

實際上你不需要主動地撒謊，只要沒有及時保持注釋和代碼更新的一致性就可以了。

只記錄顯而易見的東西

往代碼里摻進(jìn)去類似于/* 給 i 加 1 */這樣的注釋，但是永遠(yuǎn)不要記錄包或者方法的整體設(shè)計這樣的干貨。

記錄 How 而不是 Why

只解釋一個程序功能的細(xì)節(jié)，而不是它要完成的任務(wù)是什么。這樣的話，如果出現(xiàn)了一個bug，修復(fù)者就搞不清這里的代碼應(yīng)有的功能。

該寫的別寫

比如你在開發(fā)一套航班預(yù)定系統(tǒng)，那就要精心設(shè)計，讓它在增加另一個航空公司的時候至少有25處代碼需要修改。永遠(yuǎn)不要在文檔里說明要修改的位置。后來的開發(fā)人員要想修改你的代碼？門都沒有，除非他們能把每一行代碼都讀懂。

計量單位

永遠(yuǎn)不要在文檔中說明任何變量、輸入、輸出或參數(shù)的計量單位，如英尺、米、加侖等。計量單位對數(shù)豆子不是太重要，但在工程領(lǐng)域就相當(dāng)重要了。同理，永遠(yuǎn)不要說明任何轉(zhuǎn)換常量的計量單位，或者是它的取值如何獲得。要想讓代碼更亂的話，你還可以在注釋里寫上錯誤的計量單位，這是赤裸裸的欺騙，但是非常有效。如果你想做一個惡貫滿盈的人，不妨自己發(fā)明一套計量單位，用自己或某個小人物的名字命名這套計量單位，但不要給出定義。萬一有人挑刺兒，你就告訴他們，你這么做是為了把浮點數(shù)運算湊成整數(shù)運算而進(jìn)行的轉(zhuǎn)換。

坑

永遠(yuǎn)不要記錄代碼中的坑。如果你懷疑某個類里可能有bug，天知地知你知就好。如果你想到了重構(gòu)或重寫代碼的思路，看在老天爺?shù)姆萆?，千萬別寫出來。切記電影《小鹿斑比》里那句臺詞 “如果你不能說好聽的話，那就什么也不要說?！?。萬一這段代碼的原作者看到你的注釋怎么辦？萬一老板看到了怎么辦？萬一客戶看到了怎么辦？搞不好最后你自己被解雇了。一句”這里需要修改“的匿名注釋就好多了，尤其是當(dāng)看不清這句注釋指的是哪里需要修改的情況下。切記“難得糊涂”四個字，這樣大家都不會感覺受到了批評。

說明變量

永遠(yuǎn)不要對變量聲明加注釋。有關(guān)變量使用的方式、邊界值、合法值、小數(shù)點后的位數(shù)、計量單位、顯示格式、數(shù)據(jù)錄入規(guī)則等等，后繼者完全可以自己從程序代碼中去理解和整理嘛。如果老板強(qiáng)迫你寫注釋，就在方法體里胡亂多寫點，但絕對不要對變量聲明寫注釋，即使是臨時變量！

在注釋里挑撥離間

為了阻撓任何雇傭外部維護(hù)承包商的傾向，可以在代碼中散布針對其他同行軟件公司的攻擊和抹黑，特別是可能接替你工作的其中任何一家。例如：