廣東網(wǎng)站建設(shè)需要多少錢（代碼大全可復(fù)制免費）代碼大全惡搞，
將 腳本之家 設(shè)為“星標?”第一時間收到文章更新
出處：程序員魚皮（ID：coder_yupi）已獲得原公眾號的授權(quán)轉(zhuǎn)載先問大家一個小問題：你覺得看別人代碼累，還是自己寫代碼累？我相信有很多朋友會說，當然是自己寫代碼累了，要思考邏輯、要動手敲鍵盤，身心俱疲啊；但是，如果你需要經(jīng)常閱讀別人的代碼，尤其是爛代碼，答案就不一定了。
因為自己寫代碼，邏輯是自己來梳理的、代碼自己是熟悉的；但是看別人的代碼，你就要去理解別人的代碼邏輯，再加上爛代碼的加持，可能很簡單的邏輯，你都得看半天才能懂所以很多大佬在面對前人的 “屎山” 項目時，寧愿自己重寫，也不去讀爛代碼。
舉個夸張的例子：讓你實現(xiàn) 1 + 1 的求和自己寫：let sum = 1 + 1;某爛代碼可能是：let a = {};let b = {};a.toString = function() {return
1;};b.valueOf = function() {return"1";};let sum = a + b;把簡單的邏輯搞復(fù)雜，便是絕大多數(shù)程序員的拿手好戲（當然也包括我）因為我從大學(xué)就開始帶團隊做項目了嘛，所以經(jīng)常會審查團隊同學(xué)的代碼，做好二次校驗。
包括現(xiàn)在雖然開公司了，前端 / 后端同學(xué)的代碼，也都會在我這過一遍才會發(fā)布上線總之算是看了很多代碼，其中有一些真的是讓我哭笑不得下面給大家分享一些代碼片段出來，希望大家 不要學(xué)習(xí) 1、過于抽象的命名還記得咱們剛學(xué)編程的時候，變量的命名都是用的 abcdefg。
自學(xué)時這么寫完全沒問題，但是在實際項目中，如果還用過于抽象的命名，那就不太合適了比如下面這段，大家能看懂是什么意思么？const [l, setL] = useState(false);
const [d, setD] = useState();但如果我稍微完善下命名呢：const [loading, setLoading] = useState(false);
const [data, setData] = useState();很多同學(xué)應(yīng)該立刻能看懂了，一個是 “加載中” 的變量，一個是 “存儲數(shù)據(jù)” 的變量最好的代碼應(yīng)該是不用寫注釋的，因為 代碼即注釋
如果你能把命名做到 “見名知義”，看代碼的人會極度舒適2、有深度的代碼比如下面這段：if (condition1) {// 邏輯 Aif (condition2) {// 邏輯 Bif (condition3) {。
// 邏輯 Cif (condition4) {// 邏輯 D } } }}這里的深度有 2 重含義，一重是字面意思：代碼一層嵌一層、深不見底；另外一重是指真的 “很有深度” —— 指讓人看不懂。
閱讀這段代碼的感覺就像是你在一座巨大的迷宮里，每次轉(zhuǎn)彎都要判斷下是左還是右，最后你只會迷失方向如何改進呢？最簡單直接的方法就是使用早返回策略（early return）：if (!condition1) 。
// 邏輯 Areturn;if (!condition2)// 邏輯 Breturn;if (!condition3)// 邏輯 Creturn;if (!condition4)// 邏輯 Dreturn
;這樣，你的代碼就清晰了很多，閱讀這種代碼的感覺就像是走在了一條直路上，前方的路一目了然當然，還可以將一些邏輯抽象成獨立函數(shù)來簡化代碼，或者使用設(shè)計模式來優(yōu)化怎么判斷一段代碼是否過于復(fù)雜、應(yīng)該優(yōu)化了呢？這里提到一個概念：。
圈復(fù)雜度 ，這是一種量化代碼復(fù)雜程度的概念通常你代碼中的 if else 分支越多，圈復(fù)雜度就越高，代碼就越復(fù)雜企業(yè)中一般建議圈復(fù)雜度不要超過 10 - 15，我個人的編碼習(xí)慣是一般不會在代碼中出現(xiàn) 3 層以上的嵌套（除非必要）。
3、冗余代碼這是我遇到最多的問題！分為 3 種情況：能用一行代碼搞定，偏偏要寫 10 行能用一個變量或函數(shù)搞定，偏偏每次都是復(fù)制粘貼重復(fù)寫沒有用到的代碼，又不舍得刪除舉個例子，下面這段前端代碼，大家覺得有什么問題：
這是我們魚聰明 AI 前端開發(fā)過程的真實代碼 {type === DRAW_APP ? (
drawImg(image) ) : ( drawImg(currDownloadUrl || originPictureUrl || pictureUrl) )}第一眼看到這段代碼時，我就發(fā)現(xiàn)了，判斷 spinning（旋轉(zhuǎn)）的代碼邏輯比較復(fù)雜，包含了兩個
|| 邏輯而下面的 drawImg 函數(shù)的參數(shù)中，又包含了這段一模一樣的邏輯這段判斷，其實就是冗余代碼，完全沒必要寫兩遍！我調(diào)整過后的代碼如下：// 要展示的圖片地址const showPictureUrl = currDownloadUrl || originPictureUrl || pictureUrl;。
直接定義一個通用變量，寫上清晰的注釋，其他地方要使用時就無需關(guān)注內(nèi)部判斷邏輯，看注釋就行了這就是所謂的 DRY 原則（Dont Repeat Yourself） ，盡量避免代碼冗余如果你在多處寫下相同的代碼，那么當需要修改這段代碼時，你就需要在所有這些地方都修改，漏一個地方就是一個 Bug。
還有，關(guān)于項目中沒有用到的函數(shù)和變量，如果你近期沒有使用計劃，不妨就刪除或者注釋掉，別舍不得利用好 Git 版本控制系統(tǒng)，只要你的代碼提交信息寫得好，要用到被刪掉的歷史代碼時，去提交記錄里找即可注意，如果是學(xué)習(xí)時寫代碼，多保留一些也是合理的。
但企業(yè)項目中，項目代碼精簡凝練些會更好這里打個比方，寫代碼就像是我在公司里堆東西，一開始總覺得多一點沒關(guān)系，反正有空間但是，冗余代碼就像是雜物，會越堆越多，遲早有一天，會影響到你大概就分享到這里，請大家在評論區(qū) @ 出你寫爛代碼的同事吧