來源：github.com/trekhleb/state-of-the-art-shitcode

• ???? 以一種代碼已經被混淆的方式命名變量

• ???? 變量/函數混合命名風格

• ???? 不要寫注釋

• ???? 使用母語寫注釋

• ???? 盡可能混合不同的格式

• ???? 盡可能把代碼寫成一行

• ???? 不要處理錯誤

• ???? 廣泛使用全局變量

• ???? 創建你不會使用的變量

• ???? 如果語言允許，不要指定類型和/或不執行類型檢查。

• ???? 你應該有不能到達的代碼

• ???? 三角法則

• ???? 混合縮進

• ???? 不要鎖住你的依賴項

• ???? 函數長的比短的好

• ???? 不要測試你的代碼

• ???? 避免代碼風格統一

• ???? 構建新項目不需要 README 文檔

• ???? 保存不必要的代碼

---

???? 以一種代碼已經被混淆的方式命名變量

如果我們鍵入的東西越少，那么就有越多的時間去思考代碼邏輯等問題。

Good ????????

let?a?=?42;

Bad ????????

let?age?=?42;

???? 變量/函數混合命名風格

為不同慶祝一下。

Good ????????

let?wWidth?=?640; let?w_height?=?480;

Bad ????????

let?windowWidth?=?640; let?windowHeight?=?480;

???? 不要寫注釋

反正沒人會讀你的代碼。

Good ????????

const?cdr?=?700;

Bad ????????

更多時候，評論應該包含一些“為什么”，而不是一些“是什么”。如果“什么”在代碼中不清楚，那么代碼可能太混亂了。

// 700ms的數量是根據UX A/B測試結果進行經驗計算的。 //?@查看:?<詳細解釋700的一個鏈接> const?callbackDebounceRate?=?700;

???? 使用母語寫注釋

如果您違反了“無注釋”原則，那么至少嘗試用一種不同于您用來編寫代碼的語言來編寫注釋。如果你的母語是英語，你可能會違反這個原則。

Good ????????

//?Закрива?мо?модальне?в?конечко?при?виникненн??помилки. toggleModal(false);

Bad ????????

//?隱藏錯誤彈窗 toggleModal(false);

???? 盡可能混合不同的格式

為不同慶祝一下。

Good ????????

let?i?=?['tomato',?'onion',?'mushrooms']; let?d?=?[?"ketchup",?"mayonnaise"?];

Bad ????????

let?ingredients?=?['tomato',?'onion',?'mushrooms']; let?dressings?=?['ketchup',?'mayonnaise'];

???? 盡可能把代碼寫成一行

Good ????????

document.location.search.replace(/(^\?)/,'').split('&').reduce(function(o,n){n=n.split('=');o[n[0]]=n[1];return?o},{})

Bad ????????

document.location.search.replace(/(^\?)/,?'').split('&').reduce((searchParams,?keyValuePair)?=>?{keyValuePair?=?keyValuePair.split('=');searchParams[keyValuePair[0]]?=?keyValuePair[1];return?searchParams;},{} )

???? 不要處理錯誤

無論何時發現錯誤，都沒有必要讓任何人知道它。沒有日志，沒有錯誤彈框。

Good ????????

try?{//?意料之外的情況。 }?catch?(error)?{//?tss...????? }

Bad ????????

try?{//?意料之外的情況。 }?catch?(error)?{setErrorMessage(error.message);//?and/orlogError(error); }

???? 廣泛使用全局變量

全球化的原則。

Good ????????

let?x?=?5;function?square()?{x?=?x?**?2; }square();?//?現在x是25

Bad ????????

let?x?=?5;function?square(num)?{return?num?**?2; }x?=?square(x);?//?現在x是25

???? 創建你不會使用的變量

以防萬一。

Good ????????

function?sum(a,?b,?c)?{const?timeout?=?1300;const?result?=?a?+?b;return?a?+?b; }

Bad ????????

function?sum(a,?b)?{return?a?+?b; }

???? 如果語言允許，不要指定類型和/或不執行類型檢查。

Good ????????

function?sum(a,?b)?{return?a?+?b; }//?在這里享受沒有注釋的快樂 const?guessWhat?=?sum([],?{});?//?->?"[object?Object]" const?guessWhatAgain?=?sum({},?[]);?//?->?0

Bad ????????

function?sum(a:?number,?b:?number):??number?{//?當我們在JS中不做置換和/或流類型檢查時，覆蓋這種情況。if?(typeof?a?!==?'number'?&&?typeof?b?!==?'number')?{return?undefined;}return?a?+?b; }//?這個應該在轉換/編譯期間失敗。 const?guessWhat?=?sum([],?{});?//?->?undefined

???? 你應該有不能到達的代碼

這是你的 "Plan B".

Good ????????

function?square(num)?{if?(typeof?num?===?'undefined')?{return?undefined;}else?{return?num?**?2;}return?null;?//?這就是我的"Plan?B". }

Bad ????????

function?square(num)?{if?(typeof?num?===?'undefined')?{return?undefined;}return?num?**?2; }

???? 三角法則

就像鳥巢，鳥巢，鳥巢。

Good ????????

function?someFunction()?{if?(condition1)?{if?(condition2)?{asyncFunction(params,?(result)?=>?{if?(result)?{for?(;;)?{if?(condition3)?{}}}})}} }

Bad ????????

async?function?someFunction()?{if?(!condition1?||?!condition2)?{return;}const?result?=?await?asyncFunction(params);if?(!result)?{return;}for?(;;)?{if?(condition3)?{}} }

???? 混合縮進

避免縮進，因為它們會使復雜的代碼在編輯器中占用更多的空間。如果你不喜歡回避他們，那就和他們搗亂。

Good ????????

const?fruits?=?['apple','orange',?'grape',?'pineapple'];const?toppings?=?['syrup',?'cream','jam','chocolate']; const?desserts?=?[]; fruits.forEach(fruit?=>?{ toppings.forEach(topping?=>?{desserts.push([ fruit,topping]);});})

Bad ????????

const?fruits?=?['apple',?'orange',?'grape',?'pineapple']; const?toppings?=?['syrup',?'cream',?'jam',?'chocolate']; const?desserts?=?[];fruits.forEach(fruit?=>?{toppings.forEach(topping?=>?{desserts.push([fruit,?topping]);}); })

???? 不要鎖住你的依賴項

以非受控方式更新每個新安裝的依賴項。為什么堅持使用過去的版本，讓我們使用最先進的庫版本。

Good ????????

$?ls?-lapackage.json

Bad ????????

$?ls?-lapackage.json package-lock.json

???? 函數長的比短的好

不要把程序邏輯分成可讀的部分。如果IDE的搜索停止，而您無法找到所需的文件或函數，該怎么辦?

• 一個文件中10000行代碼是OK的。

• 一個函數體1000行代碼是OK的。

• 處理許多服務(第三方和內部，也有一些工具、數據庫手寫ORM和jQuery滑塊)在一個' service.js ' ?這是OK的。

???? 不要測試你的代碼

這是重復的并且不需要的工作。

???? 避免代碼風格統一

編寫您想要的代碼，特別是在一個團隊中有多個開發人員的情況下。這是一個“自由”的原則。

???? 構建新項目不需要 README 文檔

一開始我們就應該保持。

???? 保存不必要的代碼

不要刪除不用的代碼，最多是注釋掉。

往期推薦

從String中移除空白字符的多種方式！？差別竟然這么大！

為什么程序員都不喜歡使用 switch ，而是大量的 if……else if ？

為啥不能用uuid做MySQL的主鍵！？

本文由“壹伴編輯器”提供技術支

?

直面Java第329期：哪個命令可以監控虛擬機各種運行狀態信息？

深入并發第013期：拓展synchronized——鎖優化

如果你喜歡本文,

請長按二維碼，關注?Hollis.

轉發至朋友圈，是對我最大的支持。

點個?在看?

喜歡是一種感覺

在看是一種支持

↘↘↘

總結

以上是生活随笔為你收集整理的这样写的，一定是辣鸡代码！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。