忍無可忍，不吐不快。
本期不寫技術文章，單純來吐槽下公司項目里的奇葩代碼，還都是一些資深老前端寫的，希望各位對號入座。
知道了什么是爛代碼，才能寫出好代碼。
別說什么代碼和人有一個能跑就行的話，玩笑歸玩笑。
人都有菜的時候，寫出垃圾代碼無可厚非，但是工作幾年了還是寫垃圾代碼，有點說不過去。
我認為的垃圾代碼，不是你寫不出深度優先、廣度優先的算法，也不是你寫不出發布訂閱、策略模式的 if else。
我認為垃圾代碼都有一個共性：看了反胃。就是你看了天然的不舒服，看了就頭疼的代碼，比如排版極丑，沒有空格、沒有換行、沒有縮進。
優秀的代碼就是簡潔清晰，不能用策略模式優化 if else 沒關系，多幾行代碼影響不大，你只要清晰，就是好代碼。
有了差代碼、好代碼的基本標準，那我們也廢話不多說，來盤盤這些資深前端的代碼，到底差在哪里。
---------------------------------------------更新------------------------------------------------
集中回答一下評論區的問題：
1、項目是原來某大廠的項目，是當時的外包團隊寫的，整體的代碼是還行的。eslint、commitlint 之類的也是有的，只不過這些都是可以禁用的，作用全靠個人自覺。
2、后來項目被我司收購，原來的人也轉為我司員工，去支撐其他項目了。這個項目代碼也就換成我們這批新來的維護了。很多代碼是三幾年前留下的確實沒錯，誰年輕的時候沒寫過爛代碼，這是可以理解的。只不過同為三年前的代碼，為啥有人寫的簡單清晰，拆分清楚，有的就這么臟亂差呢？
3、文中提到的很多代碼其實是最近一年寫的，寫這些功能的前端都是六七年經驗的，當時因為項目團隊剛組建，沒有前端，抽調這些前端過來支援，寫的東西真的非常非常不規范，這是讓人難以理解的，他們在原來的項目組（核心產品，前端基建和規范都很厲害）也是這么寫代碼的嗎？
4、關于團隊規范，現在的團隊是剛成立沒多久的，都是些年輕人，領導也不是專業前端，基本屬于無前端 leader 的狀態，我倒是很想推規范，但是我不在其位，不好去推行這些東西，提了建議，領導是希望你簡單寫寫業務就行（說白了我不是 leader 說啥都沒用）。而且我們這些年輕前端大家都默認打開 eslint，自覺性都很高，所以暫時都安于現狀，代碼 review 做過幾次，都沒太大的毛病，也就沒繼續做了。
5、評論區還有人說想看看我寫的代碼，我前面文章有，我有幾個開源項目，感興趣可以自己去看。項目上的代碼因為涉及公司機密，沒法展示。
6、本文就是篇吐槽，也不針對任何人，要是有人看了不舒服，沒錯，說的就是你。要是沒事，大家看了樂呵樂呵就行。輕噴~
文件命名千奇百怪
同一個功能，都是他寫的，三個文件夾三種奇葩命名法，最重要的是第三個，有人能知道它這個文件夾是什么功能嗎？這完全不知道寫的什么玩意兒，每次我來看代碼都得重新理一遍邏輯。
組件職責不清
還是剛才那個組件，這個 components 文件夾應該是放各個組件的，但是他又在底下放一個 RecordDialog.jsx 作為 components 的根組件，那 components 作為文件名有什么意義呢？
條件渲染邏輯置于底層
這里其實他寫了幾個渲染函數，根據客戶和需求的不同條件性地渲染不同內容，但是判斷條件應該放在函數外，和函數調用放在一起，根據不同條件調用不同渲染函數，而不是函數內就寫條件，這里就導致邏輯內置，過于分散，不利于維護。違反了我們常說的高內聚、低耦合的編程理念。
濫用、亂用 TS
項目是三四年前的項目了，主要是類組件，資深前端們是屬于內部借調來支援維護的，發現項目連個 TS 都沒有，不像話，趕緊把 TS 配上。配上了，寫了個 tsx 后綴，然后全是無類型或者 anyscript。甚至于完全忽視 TS 和 ESlint 的代碼檢查，代碼里留下一堆紅色報錯。忍無可忍，我自己加了類型。
留下大量無用注釋代碼和報錯代碼
感受下這個注釋代碼量，我每次做需求都刪，但是幾十個工程，真的刪不過來。
丑陋的、隱患的、無效的、混亂的 css
丑陋的：沒有空格，沒有換行，沒有縮進
隱患的：大量覆蓋組件庫原有樣式的 css 代碼，不寫類名實現 namespace
無效的：大量注釋的 css 代碼，各種寫了類名不寫樣式的垃圾類名
混亂的：從全局、局部、其他組件各種引入 css 文件，導致樣式代碼過于耦合
一個文件 6 個槽點
槽點1：代碼的空行格式混亂，影響代碼閱讀
槽點2：空函數，寫了函數名不寫函數體，但是還調用了！
槽點3：函數參數過多不優化
槽點4：鏈式調用過長，屬性可能存在 undefined 或者 null 的情況，代碼容易崩，導致線上白屏
槽點5：雙循環嵌套，影響性能，可以替換為 reduce 處理
槽點6：參數、變量、函數的命名隨意而不語義化，完全不知道有何作用，且不使用小駝峰命名
變態的鏈式取值和賦值
都懶得說了，各位觀眾自己看吧。
代碼拆分不合理或者不拆分導致代碼行數超標
能寫出這么多行數的代碼的絕對是人才。
盡管說后來維護的人加了一些代碼，但是其初始代碼最起碼也有近 2000 行。
這是某個功能的數據流文件，使用 Dva 維護本身代碼量就比 Redux 少很多了，還是能一個文件寫出這么多。導致到現在根本不敢拆出去，沒人敢動。
雜七雜八的無用 js、md、txt 文件
在我治理之前，充斥著非常多的無用的、散亂的 md 文檔，只有一個函數卻沒有調用的 js 文件，還有一堆測試用的 html 文件。
實在受不了干脆建個文件夾放一塊，看起來也要舒服多了。
less、scss 混用
這是最奇葩的。
特殊變量重命名
這是真大佬，整個項目基建都是他搭的。寫的東西也非常牛，bug 很少。但是大佬有一點個人癖好，例如喜歡給 window 重命名為 G。這雖然算不上大缺點，但真心不建議大家這么做，window 是特殊意義變量，還請別重命名。
const G = window; const doc = G.document;
混亂的 import
規范的 import 順序，應該是框架、組件等第三方庫優先，其次是內部的組件庫、包等，然后是一些工具函數，輔助函數等文件，其次再是樣式文件。亂七八糟的引入順序看著都煩，還有這個奇葩的引入方式，直接去 lib 文件夾下引入組件，也是夠奇葩了。
總而言之，css 文件一般是最后引入，不能阻塞 js 的優先引入。
寫在最后
就先吐槽這么多吧，這些都是平時開發過程中容易犯的錯誤。希望大家引以為戒，不然小心被刀。
要想保持一個好的編碼習慣，寫代碼的時候就得時刻告訴自己，你的代碼后面是會有人來看的，不想被罵就寫干凈點。
我覺得什么算法、設計模式都是次要的，代碼清晰，數據流向清晰，變量名起好，基本 80% 不會太差。
不過說這么多，成事在人。
作者：北島貳
鏈接：
https://juejin.cn/post/7265505732158472249
