如何編寫不可維護的php代碼？

對於下面的定義

#define local_var xy_z


可以把 「xy_z」 打散到兩行里：

#define local_var xy
_z // local_var OK


這樣全局搜索 xy_z 的操作在這個文件里就一無所獲了。 對於 C 預處理器來說，第一行最後的 「」 表示繼續拼接下一行的內容。

任何傻瓜都能說真話，而要把謊編圓則需要相當的智慧。- Samuel Butler (1835 – 1902)

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

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

在注釋中撒謊

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

只記錄顯而易見的東西

往代碼里摻進去類似於

1

這樣的注釋，但是永遠不要記錄包或者方法的整體設計這樣的乾貨。

記錄 How 而不是 Why

只解釋一個程序功能的細節，而不是它要完成的任務是什麼。這樣的話，如果出現了一個bug，修復者就搞不清這裡的代碼應有的功能。

該寫的別寫

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

計量單位

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

坑

永遠不要記錄代碼中的坑。如果你懷疑某個類里可能有bug，天知地知你知就好。如果你想到了重構或重寫代碼的思路，看在老天爺的份上，千萬別寫出來。切記電影《小鹿斑比》里那句台詞 「如果你不能說好聽的話，那就什麼也不要說。」。萬一這段代碼的原作者看到你的注釋怎麼辦？萬一老闆看到了怎麼辦？萬一客戶看到了怎麼辦？搞不好最後你自己被解僱了。一句」這裡需要修改「的匿名注釋就好多了，尤其是當看不清這句注釋指的是哪裡需要修改的情況下。切記「難得糊塗」四個字，這樣大家都不會感覺受到了批評。

說明變數

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

在注釋里挑撥離間

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

/* 優化後的內層循環
這套技巧對於SSI軟體服務公司的那幫蠢材來說太高深了，他們只會
用 & 里的笨常式，消耗50倍的內存和處理時間。
*/
class clever_SSInc
{
.. .
}


可能的話，除了注釋之外，這些攻擊抹黑的內容也要摻到代碼里的重要語義部分，這樣如果管理層想清理掉這些攻擊性的言論然後發給外部承包商去維護，就會破壞代碼結構。

程序設計

編寫無法維護代碼的基本規則就是：在儘可能多的地方，以儘可能多的方式表述每一個事實。- Roedy Green

編寫可維護代碼的關鍵因素是只在一個地方表述應用里的一個事實。如果你的想法變了，你也只在一個地方修改，這樣就能保證整個程序正常工作。所以，編寫無法維護代碼的關鍵因素就是反覆地表述同一個事實，在儘可能多的地方，以儘可能多的方式進行。令人高興的是，像Java這樣的語言讓編寫這種無法維護代碼變得非常容易。例如，改變一個被引用很多的變數的類型幾乎是不可能的，因為所有造型和轉換功能都會出錯，而且關聯的臨時變數的類型也不合適了。而且，如果變數值要在屏幕上顯示，那麼所有相關的顯示和數據錄入代碼都必須一一找到並手工進行修改。類似的還有很多，比如由C和Java組成的Algol語言系列，Abundance甚至Smalltalk對於數組等結構的處理，都是大有可為的。

Java 造型

Java的造型機制是上帝的禮物。你可以問心無愧地使用它，因為Java語言本身就需要它。每次你從一個Collection 里獲取一個對象，你都必須把它造型為原始類型。這樣這個變數的類型就必須在無數地方表述。如果後來類型變了，所有的造型都要修改才能匹配。如果倒霉的維護代碼的程序員沒有找全（或者修改太多），編譯器能不能檢測到也不好說。類似的，如果變數類型從short 變成 int，所有匹配的造型也都要從(short) 改成 (int)。

利用Java的冗餘

Java要求你給每個變數的類型寫兩次表述。 Java 程序員已經習慣了這種冗餘，他們不會注意到你的兩次表述有細微的差別，例如

不幸的是 ++ 操作符的盛行讓下面這種偽冗餘代碼得手的難度變大了：

swimmer = swimner + 1;

永遠不做校驗

永遠不要對輸入數據做任何的正確性或差異性檢查。這樣能表現你對公司設備的絕對信任，以及你是一位信任所有項目夥伴和系統管理員的團隊合作者。總是返回合理的值，即使數據輸入有問題或者錯誤。

有禮貌，無斷言

避免使用 assert() 機制，因為它可能把三天的debug盛宴變成10分鐘的快餐。

避免封裝

為了提高效率，不要使用封裝。方法的調用者需要所有能得到的外部信息，以便了解方法的內部是如何工作的。

複製粘貼修改

以效率的名義，使用 複製+粘貼+修改。這樣比寫成小型可復用模塊效率高得多。在用代碼行數衡量你的進度的小作坊里，這招尤其管用。

使用靜態數組

如果一個庫里的模塊需要一個數組來存放圖片，就定義一個靜態數組。沒人會有比512 X 512 更大的圖片，所以固定大小的數組就可以了。為了最佳精度，就把它定義成 double 類型的數組。

傻瓜介面

編寫一個名為 「WrittenByMe」 之類的空介面，然後讓你的所有類都實現它。然後給所有你用到的Java 內置類編寫包裝類。這裡的思想是確保你程序里的每個對象都實現這個介面。最後，編寫所有的方法，讓它們的參數和返回類型都是這個 WrittenByMe。這樣就幾乎不可能搞清楚某個方法的功能是什麼，並且所有類型都需要好玩的造型方法。更出格的玩法是，讓每個團隊成員編寫它們自己的介面(例如 WrittenByJoe)，程序員用到的任何類都要實現他自己的介面。這樣你就可以在大量無意義介面中隨便找一個來引用對象了。

巨型監聽器

永遠不要為每個組件創建分開的監聽器。對所有按鈕總是用同一個監聽器，只要用大量的if…else 來判斷是哪一個按鈕被點擊就行了。

好事成堆TM

狂野地使用封裝和OO思想。例如

myPanel.add( getMyButton() );
private JButton getMyButton()
{
return myButton;
}


這段很可能看起來不怎麼好笑。別擔心，只是時候未到而已。

友好的朋友

在C++ 里盡量多使用friend聲明。再把創建類的指針傳遞給已創建類。現在你不用浪費時間去考慮介面了。另外，你應該用上關鍵字private 和 protected 來表明你的類封裝得很好。

使用三維數組

大量使用它們。用扭曲的方式在數組之間移動數據，比如，用arrayA里的行去填充arrayB的列。這麼做的時候，不管三七二十一再加上1的偏移值，這樣很靈。讓維護代碼的程序員抓狂去吧。

混合與匹配

存取方法和公共變數神馬的都要給他用上。這樣的話，你無需調用存取器的開銷就可以修改一個對象的變數，還能宣稱這個類是個」Java Bean」。對於那些試圖添加日誌函數來找出改變值的源頭的維護代碼的程序員，用這一招來迷惑他尤其有效。

沒有秘密!

把每個方法和變數都聲明為 public。畢竟某個人某天可能會需要用到它。一旦方法被聲明為public 了，就很難縮回去。對不？這樣任何它覆蓋到的代碼都很難修改了。它還有個令人愉快的副作用，就是讓你看不清類的作用是什麼。如果老闆質問你是不是瘋了，你就告訴他你遵循的是經典的透明介面原則。

全堆一塊

把你所有的沒用的和過時的方法和變數都留在代碼里。畢竟說起來，既然你在1976年用過一次，誰知道你啥時候會需要再用到呢？當然程序是改了，但它也可能會改回來嘛，你」不想要重新發明輪子」（領導們都會喜歡這樣的口氣）。如果你還原封不動地留著這些方法和變數的注釋，而且注釋寫得又高深莫測，甭管維護代碼的是誰，恐怕都不敢對它輕舉妄動。

就是 Final

把你所有的葉子類都聲明為 final。畢竟說起來，你在項目里的活兒都幹完了，顯然不會有其他人會通過擴展你的類來改進你的代碼。這種情況甚至可能有安全漏洞。 java.lang.String 被定義成 final 也許就是這個原因吧？如果項目組其他程序員有意見，告訴他們這樣做能夠提高運行速度。

避免布局

永遠不要用到布局。當維護代碼的程序員想增加一個欄位，他必須手工調整屏幕上顯示所有內容的絕對坐標值。如果老闆強迫你使用布局，那就寫一個巨型的 GridBagLayout 並在裡面用絕對坐標進行硬編碼。

全局變數，怎麼強調都不過分

如果上帝不願意我們使用全局變數，他就不會發明出這個東西。不要讓上帝失望，盡量多使用全局變數。每個函數最起碼都要使用和設置其中的兩個，即使沒有理由也要這麼做。畢竟，任何優秀的維護代碼的程序員都會很快搞清楚這是一種偵探工作測試，有利於讓他們從笨蛋中脫穎而出。

再一次說說全局變數

全局變數讓你可以省去在函數里描述參數的麻煩。充分利用這一點。在全局變數中選那麼幾個來表示對其他全局變數進行操作的類型。

局部變數

永遠不要用局部變數。在你感覺想要用的時候，把它改成一個實例或者靜態變數，並無私地和其他方法分享它。這樣做的好處是，你以後在其他方法里寫類似聲明的時候會節省時間。C++程序員可以百尺竿頭更進一步，把所有變數都弄成全局的。

配置文件

配置文件通常是以 關鍵字 = 值 的形式出現。在載入時這些值被放入 Java 變數中。最明顯的迷惑技術就是把有細微差別的名字用於關鍵字和Java 變數.甚至可以在配置文件里定義運行時根本不會改變的常量。參數文件變數和簡單變數比，維護它的代碼量起碼是後者的5倍。

子類

對於編寫無法維護代碼的任務來說，面向對象編程的思想簡直是天賜之寶。如果你有一個類，裡邊有10個屬性（成員/方法），可以考慮寫一個基類，裡面只有一個屬性，然後產生9層的子類，每層增加一個屬性。等你訪問到最終的子類時，你才能得到全部10個屬性。如果可能，把每個類的聲明都放在不同的文件里。

編碼迷局

迷惑 C

從互聯網上的各種混亂C 語言競賽中學習，追隨大師們的腳步。

追求極致

總是追求用最迷惑的方式來做普通的任務。例如，要用數組來把整數轉換為相應的字元串，可以這麼做：

char *p;
switch (n)
{
case 1:
p = "one";
if (0)
case 2:
p = "two";
if (0)
case 3:
p = "three";
printf("%s", p);
break;
}


一致性的小淘氣

當你需要一個字元常量的時候，可以用多種不同格式： 『 『, 32, 0×20, 040。在C或Java里10和010是不同的數（0開頭的表示8進位），你也可以充分利用這個特性。

造型

把所有數據都以 void * 形式傳遞，然後再造型為合適的結構。不用結構而是通過位移位元組數來造型也很好玩。

嵌套 Switch

Switch 裡邊還有 Switch，這種嵌套方式是人類大腦難以破解的。

利用隱式轉化

牢記編程語言中所有的隱式轉化細節。充分利用它們。數組的索引要用浮點變數，循環計數器用字元，對數字執行字元串函數調用。不管怎麼說，所有這些操作都是合法的，它們無非是讓源代碼更簡潔而已。任何嘗試理解它們的維護者都會對你感激不盡，因為他們必須閱讀和學習整個關於隱式數據類型轉化的章節，而這個章節很可能是他們來維護你的代碼之前完全忽略了的。

分號!

在所有語法允許的地方都加上分號，例如：

if(a);
else;
{
int d;
d = c;
}
;


使用八進位數

把八進位數混到十進位數列表裡，就像這樣：

array = new int []
{
111,
120,
013,
121,
};


嵌套

儘可能深地嵌套。優秀的程序員能在一行代碼里寫10層()，在一個方法里寫20層{}。

C數組

C編譯器會把 myArray[i] 轉換成 *(myArray + i)，它等同於 *(i + myArray) 也等同於 i[myArray]。 高手都知道怎麼用好這個招。可以用下面的函數來產生索引，這樣就把代碼搞亂了：

int myfunc(int q, int p) { return p%q; }
...
myfunc(6291, 8)[Array];


遺憾的是，這一招只能在本地C類里用，Java 還不行。

放長線釣大魚

一行代碼里堆的東西越多越好。這樣可以省下臨時變數的開銷，去掉換行和空格還可以縮短源文件大小。記住，要去掉運算符兩邊的空格。優秀的程序員總是能突破某些編輯器對於255個字元行寬的限制。

異常

在這裡我要向你傳授一個編程領域裡鮮為人知的秘訣。異常是個討厭的東西。良好的代碼永遠不會出錯，所以異常實際上是不必要的。不要把時間浪費在這上面。子類異常是給那些知道自己代碼會出錯的低能兒用的。在整個應用里，你只用在main()里放一個try/catch，裡邊直接調用 System.exit()就行了。在每個方法頭要貼上標準的拋出集合定義，至於會不會拋出異常你就甭管了。

使用異常的時機

在非異常條件下才要使用異常。比如終止循環就可以用 ArrayIndexOutOfBoundsException。還可以從異常里的方法返回標準的結果。

狂熱奔放地使用線程

如題。

測試

在程序里留些bug，讓後繼的維護代碼的程序員能做點有意思的事。精心設計的bug是無跡可尋的，而且誰也不知道它啥時候會冒出來。要做到這一點，最簡單的辦法的就是不要測試代碼。

永不測試

永遠不要測試負責處理錯誤、當機或操作系統故障的任何代碼。反正這些代碼永遠也不會執行，只會拖累你的測試。還有，你怎麼可能測試處理磁碟錯誤、文件讀取錯誤、操作系統崩潰這些類型的事件呢？為啥你要用特別不穩定的計算機或者用測試腳手架來模擬這樣的環境？現代化的硬體永遠不會崩潰，誰還願意寫一些僅僅用於測試的代碼？這一點也不好玩。萬一將來出了事用戶抱怨，你就怪到操作系統或者硬體頭上。他們永遠不會知道真相的。

永遠不要做性能測試

嘿，如果軟體運行不夠快，只要告訴客戶買個更快的機器就行了。如果你真的做了性能測試，你可能會發現一個瓶頸，這會導致修改演算法，然後導致整個產品要重新設計。誰想要這種結果？而且，在客戶那邊發現性能問題意味著你可以免費到外地旅遊。你只要備好護照和最新照片就行了。

永遠不要寫任何測試用例

永遠不要做代碼覆蓋率或路徑覆蓋率測試。自動化測試是給那些窩囊廢用的。搞清楚哪些特性佔到你的常式使用率的90%，然後把90%的測試用在這些路徑上。畢竟說起來，這種方法可能只測試到了大約你代碼的60%，這樣你就節省了40%的測試工作。這能幫助你趕上項目後端的進度。等到有人發現所有這些漂亮的「市場特性」不能正常工作的時候，你早就跑路了。一些有名的大軟體公司就是這樣測試代碼的，所以你也應該這樣做。如果因為某種原因你還沒走，那就接著看下一節。

測試是給懦夫用的

勇敢的程序員會跳過這個步驟。太多程序員害怕他們的老闆，害怕丟掉工作，害怕客戶的投訴郵件，害怕遭到起訴。這種恐懼心理麻痹了行動，降低了生產率。有科學研究成果表明，取消測試階段意味著經理有把握能提前確定交付時間，這對於規劃流程顯然是有利的。消除了恐懼心理，創新和實驗之花就隨之綻放。程序員的角色是生產代碼，調試工作完全可以由技術支持和遺留代碼維護組通力合作來進行。

如果我們對自己的編程能力有充分信心，那麼測試就沒有必要了。如果我們邏輯地看待這個問題，隨便一個傻瓜都能認識到測試根本都不是為了解決技術問題，相反，它是一種感性的信心問題。針對這種缺乏信心的問題，更有效的解決辦法就是完全取消測試，送我們的程序員去參加自信心培訓課程。畢竟說起來，如果我們選擇做測試，那麼我們就要測試每個程序的變更，但其實我們只需要送程序員去一次建立自信的培訓課就行了。很顯然這麼做的成本收益是相當可觀的。

計算機語言正在逐步進化，變得更加傻瓜化。使用最新的語言算什麼好漢？儘可能堅持使用你會用的最老的語言，先考慮用穿孔紙帶，不行就用彙編，再不行用FORTRAN 或者 COBOL，再不行就用C 還有 BASIC，實在不行再用 C++。

用 FORTRAN 寫所有的代碼。如果老闆問你為啥，你可以回答說它有很多非常有用的庫，你用它可以節約時間。不過，用 FORTRAN 寫出可維護代碼的概率是 0，所以，要達到不可維護代碼編程指南里的要求就容易多了。

用 ASM

把所有的通用工具函數都轉成彙編程序。

用 QBASIC

所有重要的庫函數都要用 QBASIC 寫，然後再寫個彙編的封包程序來處理 large 到 medium 的內存模型映射。

內聯彙編

在你的代碼里混雜一些內聯的彙編程序，這樣很好玩。這年頭幾乎沒人懂彙編程序了。只要放幾行彙編代碼就能讓維護代碼的程序員望而卻步。

宏彙編調用C

如果你有個彙編模塊被C調用，那就儘可能經常從彙編模塊再去調用C，即使只是出於微不足道的用途，另外要充分利用 goto, bcc 和其他炫目的彙編秘籍。

與他人共事之道

老闆才是真行家

如果你的老闆認為他20年的 FORTRAN 編程經驗對於現代軟體開發具有很高的指導價值，你務必嚴格採納他的所有建議。投桃報李，你的老闆也會信任你。這會對你的職業發展有利。你還會從他那裡學到很多搞亂程序代碼的新方法。

顛覆技術支持

確保代碼中到處是bug的有效方法是永遠不要讓維護代碼的程序員知道它們。這需要顛覆技術支持工作。永遠不接電話。使用自動語音答覆「感謝撥打技術支持熱線。需要人工服務請按1，或在嘀聲後留言。」，請求幫助的電子郵件必須忽略，不要給它分配服務追蹤號。對任何問題的標準答覆是「我估計你的賬戶被鎖定了，有許可權幫你恢復的人現在不在。」

沉默是金

永遠不要對下一個危機保持警覺。如果你預見到某個問題可能會在一個固定時間爆發，摧毀西半球的全部生命，不要公開討論它。不要告訴朋友、同事或其他你認識的有本事的人。在任何情況下都不要發表任何可能暗示到這種新的威脅的內容。只發送一篇正常優先順序的、語焉不詳的備忘錄給管理層，保護自己免遭秋後算賬。如果可能的話，把這篇稀里糊塗的信息作為另外一個更緊急的業務問題的附件。這樣就可以心安理得地休息了，你知道將來你被強制提前退休之後一段時間，他們又會求著你回來，並給你對數級增長的時薪！

每月一書俱樂部

加入一個計算機每月一書俱樂部。選擇那些看上去忙著寫書不可能有時間真的去寫代碼的作者。去書店裡找一些有很多圖表但是沒有代碼例子的書。瀏覽一下這些書，從中學會一些迂腐拗口的術語，用它們就能唬住那些自以為是的維護代碼的程序員。你的代碼肯定會給他留下深刻印象。如果人們連你寫的術語都理解不了，他們一定會認為你非常聰明，你的演算法非常深奧。不要在你的演算法說明裡作任何樸素的類比。

自立門戶

你一直想寫系統級的代碼。現在機會來了。忽略標準庫， 編寫你自己的標準，這將會是你簡歷中的一大亮點。

推出你自己的 BNF 範式

總是用你自創的、獨一無二的、無文檔的BNF範式記錄你的命令語法。永遠不要提供一套帶註解的例子（合法命令和非法命令之類）來解釋你的語法體系。那樣會顯得完全缺乏學術嚴謹性。確保沒有明顯的方式來區分終結符和中間符號。永遠不要用字體、顏色、大小寫和其他任何視覺提示幫助讀者分辨它們。在你的 BNF 範式用和命令語言本身完全一樣的標點符號，這樣讀者就永遠無法分清一段 (…), [...], {…} 或 「…」 到底是你在命令行里真正輸入的，還是想提示在你的BNF 範式里哪個語法元素是必需的、可重複的、或可選的。不管怎麼樣，如果他們太笨，搞不清你的BNF 範式的變化，就沒資格使用你的程序。

推出你自己的內存分配

地球人兒都知道，調試動態存儲是複雜和費時的。與其逐個類去確認它沒有內存溢出，還不如自創一套存儲分配機制呢。其實它無非是從一大片內存中 malloc 一塊空間而已。用不著釋放內存，讓用戶定期重啟動系統，這樣不就清除了堆么。重啟之後系統需要追蹤的就那麼一點東西，比起解決所有的內存泄露簡單得不知道到哪裡去了！而且，只要用戶記得定期重啟系統，他們也永遠不會遇到堆空間不足的問題。一旦系統被部署，你很難想像他們還能改變這個策略。

其他雜七雜八的招

如果你給某人一段程序，你會讓他困惑一天；如果你教他們如何編程，你會讓他困惑一輩子。 — Anonymous

不要重編譯

挫敗調試工具

公制和美製

持續改進

「關於」

變更

無需技能

只帶一把鎚子

規範體系

翻轉通常的 True False 慣例

#define TRUE 0
#define FALSE 1


把這個定義深深地藏在代碼中某個沒人會再去看的文件里不易被發現的地方，然後讓程序做下面這樣的比較

if ( var == TRUE )
if ( var != FALSE )


某些人肯定會迫不及待地跳出來「修正」這種明顯的冗餘，並且在其他地方照著常規去使用變數var：

if ( var )


還有一招是為 TRUE 和 FALSE賦予相同的值，雖然大部分人可能會看穿這種騙局。給它們分別賦值 1 和 2 或者 -1 和 0 是讓他們瞎忙乎的方式里更精巧的，而且這樣做看起來也不失對他們的尊重。你在Java 里也可以用這一招，定義一個叫 TRUE 的靜態常量。在這種情況下，其他程序員更有可能懷疑你乾的不是好事，因為Java里已經有了內建的標識符 true。

第三方庫

不要用庫

創建一套Build順序

Make 的更多玩法

搜集編碼規範

規避公司的編碼規則

#define K_ONE 1
#define K_TWO 2
#define K_THOUSAND 999


編譯器警告

把 bug 修復和升級混在一起

在你的產品發布每個新版本的時候都改變文件結構

抵消 Bug

使用旋轉鎖

隨意安插 sync 代碼

優雅降級

定製腳本語言

依賴於編譯器的代碼

一個貨真價實的例子

void* Realocate(void*buf, int os, int ns)
{
void*temp;
temp = malloc(os);
memcpy((void*)temp, (void*)buf, os);
free(buf);
buf = malloc(ns);
memset(buf, 0, ns);
memcpy((void*)buf, (void*)temp, ns);
return buf;
}


• 重新發明了標準庫里已有的簡單函數。
• Realocate 這個單詞拼寫錯誤。所以說，永遠不要低估創造性拼寫的威力。
• 無緣無故地給輸入緩衝區產生一個臨時的副本。
• 無緣無故地造型。 memcpy() 里有 (void*)，這樣即使我們的指針已經是 (void*) 了也要再造型一次。另外，這樣做可以傳遞任何東西作為參數，加10分。
• 永遠不必費力去釋放臨時內存空間。這樣會導致緩慢的內存泄露，一開始看不出來，要程序運行一段時間才行。
• 把用不著的東西也從緩衝區里拷貝出來，以防萬一。這樣只會在Unix上產生core dump，Windows 就不會。
• 很顯然，os 和 ns 的含義分別是」old size」 和 「new size」。
• 給 buf 分配內存之後，memset 初始化它為 0。不要使用 calloc()，因為某些人會重寫 ANSI 規範，這樣將來保不齊 calloc() 往 buf 里填的就不是 0 了。（雖然我們複製過去的數據量和 buf 的大小是一樣的，不需要初始化，不過這也無所謂啦）

如何修復 「unused variable」 錯誤

如果你的編譯器冒出了 「unused local variable」 警告，不要去掉那個變數。相反，要找個聰明的辦法把它用起來。我最喜歡的方法是：

i = i;


大小很關鍵

一張圖片頂1000句話，一個函數就是1000行

少個文件

#include &


Stdcode.h 是有的。但是在 stdcode.h 里，還有個引用：

#include "a:\refcode.h"


然後，refcode.h 就沒地方能找到了。

（【譯者注】為啥找不到呢？仔細看看，現在還有人知道 a: 是什麼嗎？A盤！傳說中的軟盤…）

到處都寫，無處會讀

這個話題，我敢肯定不少開發者有思考過！但畢竟不是什麼光明正大的事情，自己做就是了，在項目高調使用就傻逼了。或許樓主不是這樣的，只是想拿出來消遣一下大家，找個話題來讓大家發揮罷了。

既然是消遣，我就誰便聊聊。

----------------

「因為沒人能搞定你的代碼，那意味著你的工作是不可替代的，誰也取代不了你。你找了個鐵飯碗。」這是一個偽命題，碼農自己的意淫。

ok，我假設存在不可維護的代碼。

請問這樣的代碼還是得由你來維護吧？也就是說，還是有人來維護的，只是別人維護起來不太合適或不太方便而已。既然這樣，按我們這一行的規矩，領導是不在乎你用什麼方法和技術的，只會給一個截止時間讓你來完成，對吧？

在這種情況下，這樣的代碼會只會讓你陷入毫無節制的無謂的加班。除非這個項目不重要，但又需要有人來維護，那麼確實可以獲得某種相對穩固的飯碗。但不重要的項目，誰會花高價請一個碼農來維護呢？不會太高的，企業不會是傻子！

然而，人又是需要往高處走的，畢竟這個社會很現實，誰也不會跟錢有仇。很難維護的代碼最後只能讓你越陷越深，最後要麼自己滾蛋，要麼繼續拿著差不多的薪水，如果這就是你想要的鐵飯碗，那麼我就無話可說了。

請問這種事情你會幹嗎？

很多碼農自己總是認為自己最聰明，能寫出一些相對難維護的代碼就以為自己在智商上高別人一籌，別那麼天真好嗎？?的好多碼農就是這樣，以為能寫個程序就裝逼，總以為別人是傻逼。

好吧，假設普通碼農智商只有120，而你是130甚至140以上，請問這種差別在做人做事上會有本質的差別嗎？

其實啊，正常人的智商都差不了太多的，對於別人不可以維護，意味著你維護起來也不太容易。同理，你維護起來容易的，別人就不會太難，只要開發經驗差不多，熟悉只是多一點點時間而已，因而不存在絕對維護不了的代碼，只是不太願意去維護罷了，別自我意淫——「我的代碼不可維護」可以嗎？

的確，我不否認存在很難維護的代碼，但是如果一個人要是以這樣的心態去書寫代碼，他的修為一定是有限的，因為代碼能力和程序造詣需要大量的項目去實踐。

或許，一兩個項目沒有人發現你是這樣的心態，但我相信能夠大多人或項目一定存在能識別這種鬼魅伎倆的人存在，而且一定不少。因此，重要的核心的項目會讓這樣的人去負責嗎？或者，只讓你一個人去負責嗎？

這是不太可能的。如果不能有太多的機會獨立去實現那些重要的核心的項目，請問你的代碼修為又怎麼提高呢？如果你是天才，天生就牛逼，請問這樣的你又何必寫不可維護的代碼呢？

所以，正真牛逼的程序開發者是不屑於去書那些「寫不可維護」的代碼的！因為這對他自己沒有任何好處！

-----下面講一個我碰到碼農的故事-----

當然，一開始的時候我安排給他的事都能順利完成，但是卻總是有些做法讓人不能接受，比如使用aaa,bbb,ccc,zzz這樣的變數名。當然，這也是我們沒有做好規範，而且自己身上還一大堆業務要親自去寫，發現這樣的問題後就他為什麼要這樣做？

回復就是，時間趕，先實現邏輯再回來改。好吧，這是事實。我認了，進度確實很趕，自己都自身難保，先過了吧。

就這樣項目上了線，1個多星期趕一個交互比較複雜的電商側邊欄項目（天貓、VIP、聚美等電商右側那個黑色工具條）。當我回頭看他實現的那部分代碼，雖說說不上不可維護，但確實很難改，因為很多沒有意義的變數名，一會兒駝峰一會兒蛇線，還有很多沒有注釋的高度抽象的函數（如果有興趣，我可以發一份給大家瞅瞅），截個圖證明一下，這已是我重新格式化後的代碼了：

我把他招進來是看到他多年的開發經驗，就沒再細看他做的代碼，或者說覺得沒必要沒要看原來的代碼，就這樣進來了。而且，價格很便宜，轉正9K，試用期7.5K。別誤會，這是他自己開的價格，我立馬找HR確認了這個價格，讓他趕緊把人弄過來，10年以上的程序開發經驗只要白菜價，這等好事哪裡找啊？

但是，和他合作了一個項目之後，我後悔了。當時他試用期還沒過，我是想把他開掉了，但是找不到人來負責，我自己有一大堆雜事，只好又忍了。其實，從這點上看，我?的也不是什麼好鳥，反正工資又不是我開，那些個爛代碼又不想自己去弄，項目上線後公司又給我升職又加薪的，懶得煩這個問題，就這樣讓他混過了試用期。

但是，這個項目到了2015年後，投資人打算撤資，於是團隊面臨解散。我們核心的技術團隊和市場團隊找到了新的投資商，重啟了一個品牌和域名繼續干。我依然負責前端架構和新項目的發版流程設計，但這個10年的碼農是唯一一個被剔除出局的，後來就沒再直接聯繫。有同事說，他後來加入了一個新公司，薪水翻翻，但不到1個月就被開掉了，不知道什麼原因。

好吧，這就是書寫無可維護代碼的碼農的故事。絕對真人真事。

說實話，後來我自己重新實現了一遍他的業務，其實沒什麼難度。經過這個事情之後，我現在負責的項目，如果有發現這樣的人，不管他多牛逼，我一定不會忍。就今年國慶前吧，我們的項目就有一個15K的前端，能力不錯，就因為又類似的代碼跡象，就在項目攻關雙節大促前夕，我依然把人開掉了，殺雞給猴看。

當然，我不知道為什麼有人做了10年的開發都可以忍受7-8K的薪水，而我?一個2年多的前端少於30K是絕對不幹的，就因為從來沒有想過書寫別人難以維護的代碼，而是希望當我請假的時候，項目中能力最弱的那個人也能修改我出產的代碼。

就這樣，你可以說我吹牛，不爽就噴我。又不會少收RMB，股份期權又沒少掉，噴吧。

熟讀下面的條款，然後反過來做

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren"t special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you"re Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it"s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let"s do more of those!


1、保證變數的龐大數量，無論有用的還是無用的。

不要為變數和函數隨便地取名！！！

不可維護的代碼寫起來並不難，但是：如果老闆讓你在現有的功能想加一個功能的時候，請問你怎麼來維護自己的代碼？

另外，你這樣做，當老闆把你送上法庭的時候，你可能發現，你欠下的債，是你一輩子都還不清的。

===============2015年10月13日更新==================

小的時候，我爸爸帶著我和我弟弟在山上勞動。 我和我弟弟心血來潮就想學著大人去用鋸子鋸樹，但是力量不足的情況下，我和我弟弟費了關天的力氣才鋸完，鋸痕還非常 不齊。

所以，覺得你盡量的寫好，然後接手的人依然會很頭大，名種搞不懂。做為一個接手過這種代碼的過來人來說，人家根本不會維護的，直接推倒重建。

本來看著題目以為提問者是想避免寫出不可維護的代碼，看完描述後只想離題地說一下自己的想法，很短，也是我自己要學習編程的想法。

這不是我在貼吧的帖子嗎？

我說說當初發這個帖子的初衷，我在一個國外網站看到的一篇文章，當時覺得很有意思，外國的程序員展開了熱情洋溢的討論。還給出了許多富有建設性具體指導（續寫了一篇詳細的）。

當時我想翻譯來的，但是沒有時間，就草草總結一下修改了少部分內容以適應國情，由於是倉促間寫出來的，就發到了對質量要求不高的貼吧里。

有意思的是中外網友的回復區別真很大。 其實不光這篇文章，在youtube，reddit，和貼吧很多帖子都能體現。