以一種代碼已經(jīng)被混淆的方式命名變量

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

Good ????????

let?a?=?42;

Bad ????????

let?age?=?42;

變量/函數(shù)混合命名風格

為不同慶祝一下。

Good ????????

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

Bad ????????

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

不要寫注釋

反正沒人會讀你的代碼。

Good ????????

const?cdr?=?700;

Bad ????????

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

// 700ms的數(shù)量是根據(jù)UX A/B測試結果進行經(jīng)驗計算的。 //?@查看:?<詳細解釋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;},{} )

不要處理錯誤

無論何時發(fā)現(xiàn)錯誤，都沒有必要讓任何人知道它。沒有日志，沒有錯誤彈框。

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();?//?現(xiàn)在x是25

Bad ????????

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

創(chuàng)建你不會使用的變量

以防萬一。

Good ????????

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

Bad ????????

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

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

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

函數(shù)長的比短的好

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

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

• 一個函數(shù)體1000行代碼是OK的。

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

不要測試你的代碼

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

避免代碼風格統(tǒng)一

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

構建新項目不需要 README 文檔

一開始我們就應該保持。

保存不必要的代碼

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

按上面的"Good"方法操作一遍，你會發(fā)現(xiàn)公司離不開你了。就是醫(yī)院的WIFI信號可能不大好，不能愉快的看公眾號了。

來源：

https://github.com/trekhleb/state-of-the-art-shitcode

由于微信平臺算法改版，公號內(nèi)容將不再以時間排序展示，如果大家想第一時間看到我們的推送，強烈建議星標我們和給我們多點點【在看】。星標具體步驟為：（1）點擊頁面最上方“小詹學Python”，進入公眾號主頁。 （2）點擊右上角的小點點，在彈出頁面點擊“設為星標”，就可以啦。 感謝支持，比心。

總結

以上是生活随笔為你收集整理的哎，辣鸡代码书写准则的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。