如何寫出沒法維護的代碼

類命名:

　　容易輸入的名字。好比：qwe，asdf
　　單字母的變量名。好比：a,b,c, x,y,z（注：若是不夠用，能夠考慮a1,a2,a3,a4,….）
　　有創意地拼寫錯誤。好比：SetPintleOpening，SetPintalClosing。這樣可讓人很難搜索代碼。
　　抽象。好比：listdate,newdate… 抽象到就跟什麼都沒說同樣。
　　縮寫。好比：WTF，RTFSC …… （注：使用拼音縮寫也一樣給力，好比： BT，TMD）
　　隨機大寫字母。好比：gEtnuMbER..
　　重用命名。在內嵌的語句塊中使用相同的變量名有奇效。
　　使用重音字母。好比：int ínt（注：第二個 ínt不是int）
　　使用不一樣的語言。好比混用英語，德語，或是中文拼音。
　　使用字符命名。好比：slash, asterix, comma…
　　使用無關的單詞。好比：god, superman, iloveu….
　　混淆l和1。字母l和數字1有時候是看不出來的。

假裝欺詐:

1. 把註釋和代碼交織在一塊兒
　　#play_text { position:absolute; right:0; bottom:0; z-index:1002;}
　　/*#play_text { position:absolute; right:5; bottom:5; z-index:1002;}*/
　　#play_text ul { padding-top:1px;  _padding-top:0; list-style-type:none; display:block;}
　　#play_text ul li { width:242px; height:29px; font-weight:bold; font-size:12px;
　　background:url(../images/jd_nav_04.png) no-repeat right ;
　　/*background:url(../images/jd_nav_04.png) no-repeat left;*/
　　/*background:url(../images/jd_nav_05.png) no-repeat right ;*/

2. 代碼和顯示不一致。
　　eg:前臺看到的代碼明明是行業新聞列表模塊，頁面內文字和註釋寫的倒是最新新聞列表。（注：重用模塊註釋就不用重用了吧）

3. 使用類似的類命名。如：
　　單詞類似，new_list 和 news_list，
　　字母類似：ilI1| 或 oO08。 D0Calc 和 DOCalc。
　　還有這一組：xy_Z, xy__z, _xy_z, _xyz, XY_Z,。

文檔和註釋

　　在註釋中撒謊：你不用真的去撒謊，只需在改代碼的時候不要更新註釋就能夠了。
　　注重細節：每條css樣式都加上註釋，越詳細越好。最好註釋比代碼還要多好多倍。

混亂你的代碼

　　註釋什麼的不要對應位置。
　　html css js 甚至xml都寫到一塊兒，都寫到頁面裏。
　　三不：不空行不回車不縮進

測試

　　從不測試：千萬不要測試任何的頁面兼容性，ie6會讓你瘋掉的。
　　永遠不作性能測試：什麼加載速度，什麼載入文件速度，什麼圖片過大。都不要去理會。
　　不要寫測試文檔：測試內容，測試結果，修改結果。都不用寫到文檔上。別讓其餘人知道你作過測試了 。
　　測試是懦夫行爲：一個勇敢的前端開發人員是根本不須要這一步的。太多的前端開發太懼怕他們的老闆 ，懼怕失去工做，懼怕用戶抱怨。這種擔憂懼怕直接影響了生產力和工做效率。若是你對你的代碼有強大的信心，那還要什麼測試呢？真正的前端開發是不須要測試本身的代碼的。尤爲是頁面兼容性，IE6 就是浮雲。

其它

　　你的老闆什麼都知道：不管你的老闆有多SB，你都要嚴格地遵守他的旨意辦事，這樣一來，你會學到更多的知識如何寫出沒法維護的代碼來的。
　　閉嘴：對於一些像頁面不兼容主流瀏覽器的bug，你要學會守口如瓶，不要告訴任何人，這樣當到經理讓客戶看頁面發現的時候，你就能夠用本身已經測試過的修改bug的方法快速修改好，以證實本身的實力。
　　忽悠：你會學會忽悠，就算你的代碼寫得很爛，你也要說徹底符合W3C、符合國際標準、符合用戶習慣 ，這樣慢慢的你的爛代碼就會成爲標準代碼，你們共同窗習的代碼。