沒有對比就沒有傷害，優秀的代碼VS糟糕的代碼

可持續開發不只在於項目架構設計，還與代碼質量密切相關，代碼的整潔度和質量成正比。—— Robert C. Martin, 「Clean Code」
若是你尚未發現代碼質量的區別，若是你從未見過優秀的代碼，或者從未見過糟糕的代碼，那麼本文將以直觀地對比，告訴你代碼質量究竟會有多大的區別。
代碼量
咱們知道代碼量顯示着功能的複雜程度，例如Windows XP的代碼量超過2000萬行，Linux內核有1500萬行（2012年）。然而代碼量和功能數量之間並不是線性關係。
優秀的設計中，代碼量和功能數的關係是這樣的：

糟糕的設計中，代碼量和功能數的關係是這樣的：

優秀的系統每每會有優秀的結構設計：層次清晰、職責單1、模塊化，方便擴展或者複用。功能的添加每每只是在現有框架中添加少許代碼。
然而糟糕的設計中，層次混亂、互相耦合、難以閱讀，既難以複用又不易擴展。每當被要求添加功能時，不得不幾乎完整地實現整個功能的流程，並修復與原系統的全部兼容問題。
註釋

優秀的代碼中，註釋是這樣的：

糟糕的代碼中，註釋是這樣的：
最愚蠢的程序員都能寫出機器能讀懂的代碼，而優秀的程序員能寫出人能夠讀懂的代碼。
程序的註釋是爲了讓人讀得懂。多數優秀的代碼中，註釋幾乎接近代碼行數的一半，描述函數功能、解釋參數配置、指出陷阱所在。而糟糕的代碼中不只不含這些註釋，甚至會保留大量殘餘代碼，可讀性差又難以重構。
命名
優秀的代碼中，命名是這樣的：

糟糕的代碼中，命名是這樣的：

命名是爲了讓代碼更加容易閱讀，使用規範的術語不只更加易懂，同時也是開發者知識水平和開發經驗的表現。若是說以中文拼音命名顯得奇怪，那麼直接以a, b, c, d命名的便會顯得可恨，誰記得你的a是神馬東西！
看一個經典的例子，字符串替換：

稍微有點Java常識的便會想到正則表達式：
何須拷貝這一堆的代碼給老闆看呢？開發中確實有不少時候，直接拷貝代碼既能立竿見影地完成功能，又不會影響原有功能。但這樣的代碼多起來以後，萬一功能調整你便須要從新debug全部的副本。花一些時間學習更優雅的用法是值得的。
函數
保持函數的短小，使你的代碼更加易讀，例如：

將複雜的邏輯分步驟完成。若是寫在一塊兒將會是這樣的：

相信我，一旦你寫了這樣的函數，它會隨着時間的推移變得愈來愈長，直到有一天，你也忘了其中的一段代碼究竟是作什麼的。
事實上，複雜的函數不只能夠按照步驟劃分，更應按照層次來細化。不要在一個函數中進行不一樣層次的操做，不然它會變得很是難懂。

相信仍是有想要學習或者瞭解web前端編程的小夥伴，能夠來個人web前端學習裙哦575308719能夠免費領取精品的web前端學習教程哦！