垃圾代碼書寫準則
還記得雷布斯這句話嗎？
好的代碼可以像詩一樣優(yōu)雅，然而并非人人都能寫的一手好代碼！老實說，想寫一手不被同事吐槽的代碼確實不容易，特別是有的小伙伴在工作中公司都沒有明確的代碼規(guī)范，或者僅僅只是一些口頭約定，這樣就更難養(yǎng)成一些良好的代碼書寫習(xí)慣了。
不過 IDEA 中有一個 Alibaba 代碼規(guī)范插件，可以自己裝著起一個約束提醒自己的作用。
最近在 GitHub 上看到一個開源項目，還挺有意思的，作者羅列出了什么樣的代碼是垃圾代碼，倉庫地址如下：
https://github.com/trekhleb/state-of-the-art-shitcode
小伙伴們不妨看一看，你有沒有中招。
垃圾代碼書寫準則
? 以一種代碼已經(jīng)被混淆的方式命名變量
如果我們鍵入的東西越少，那么就有越多的時間去思考代碼邏輯等問題。
Good ??
let?a?=?42;
Bad ??
let?age?=?42;
? 變量/函數(shù)混合命名風(fēng)格
為不同慶祝一下。
Good ??
let?wWidth?=?640;
let?w_height?=?480;
Bad ??
let?windowWidth?=?640;
let?windowHeight?=?480;
? 不要寫注釋
反正沒人會讀你的代碼。
Good ??
const?cdr?=?700;
Bad ??
更多時候，評論應(yīng)該包含一些“為什么”，而不是一些“是什么”。如果“什么”在代碼中不清楚，那么代碼可能太混亂了。
// 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;
}
//?這個應(yīng)該在轉(zhuǎn)換/編譯期間失敗。
const?guessWhat?=?sum([],?{});?//?->?undefined
? 你應(yīng)該有一些不能運行到的代碼
這是你的 "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)?{
????}
??}
}
? 混合縮進
避免縮進，因為它們會使復(fù)雜的代碼在編輯器中占用更多的空間。如果你不喜歡回避他們，那就和他們搗亂。
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的。 處理許多服務(wù)(第三方和內(nèi)部，也有一些工具、數(shù)據(jù)庫手寫ORM和jQuery滑塊)在一個' service.js ' ?這是OK的。
? 不要測試你的代碼
這是重復(fù)的并且不需要的工作。
? 避免代碼風(fēng)格統(tǒng)一
隨心所欲的寫代碼，特別是在一個團隊中有多個開發(fā)人員的情況下。這是一個“自由”的原則。
? 構(gòu)建新項目不需要 README 文檔
一開始我們就應(yīng)該保持。
? 保存不必要的代碼
不要刪除不用的代碼，最多是注釋掉。
來源丨江南一點雨
——————END——————
歡迎關(guān)注“Java引導(dǎo)者”，我們分享最有價值的Java的干貨文章，助力您成為有思想的Java開發(fā)工程師！