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

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測試結(jié)果進行經(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/or
??logError(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;
}

//?這個應該在轉(zhuǎn)換/編譯期間失敗。
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?-la

package.json

Bad ??

$?ls?-la

package.json
package-lock.json

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

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

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

不要測試你的代碼

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

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

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

構(gòu)建新項目不需要 README 文檔

一開始我們就應該保持。

保存不必要的代碼

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

推薦閱讀：

• 阿里巴巴官方最新Redis開發(fā)規(guī)范！
  

• Spring Boot 2.3.3 穩(wěn)定版發(fā)布！修復了這18個Bug！！
  

• 肝完這篇 TCP/IP ，我就去面試去。
  

• 這個在阿里內(nèi)網(wǎng)挨罵的程序員 做出了最受歡迎的開源軟件
  

喜歡我可以給我設為星標哦

好文章，我“在看”