前兩天看到一則代碼注釋里出現(xiàn)各種臟話的消息，這讓我想起了之前看過的一個(gè)很有意思的開源項(xiàng)目。

有一端時(shí)間，這個(gè)項(xiàng)目簡直火得不行~

教你怎樣寫出不被同事罵的代碼。

項(xiàng)目一共列出了 20 條建議之多，這里月亮挑幾條最有意思的分享出來。

變量名越簡單越好

比如，變量名用 a 替代 age。

原本需要打三個(gè)字母的時(shí)間，直接節(jié)省了 2/3 ，每天的工作效率直接爆表。

至于可讀性？

那是你一個(gè)碼農(nóng)應(yīng)該考慮的問題嗎？

相信我，怎么快怎么來。

//推薦寫法
leta=42;
//不推薦寫法
letage=42;

不要寫注釋

千萬不要寫注釋，寫注釋花費(fèi)的時(shí)間，都足夠你多寫好幾個(gè)功能的代碼了。

而且你想想，公司招人都會(huì)選擇技術(shù)成熟的程序員。

沒有注釋就看不懂代碼了？

那豈不是不具備較強(qiáng)的讀程能力？

你不寫注釋，我認(rèn)為沒有問題，如果你的同事真的讀不懂，說明他需要反思自己的專業(yè)能力了。

記住啦，千萬不要寫注釋，要相信你的同事~

ps：寫到這里，突然想起一個(gè)段子。

每個(gè)程序員最討厭做的事情：寫注釋。

每個(gè)程序員最討厭其他程序員做的事情：不寫注釋。

盡可能把代碼寫成一行

把代碼寫成一行，可以減少不必要的存儲(chǔ)空間消耗。

數(shù)據(jù)占用的存儲(chǔ)空間越小，在網(wǎng)絡(luò)中傳輸?shù)乃俣染蜁?huì)越快。

在移動(dòng)互聯(lián)網(wǎng)高速發(fā)展的今天，加快數(shù)據(jù)傳輸，絕對(duì)是能極大的提高用戶體驗(yàn)的操作。

所以，盡量把代碼寫成一行，好處非常多。

//推薦寫法
document.location.search.replace(/(^?)/,'').split('&').reduce(function(o,n){n=n.split('=');o[n[0]]=n[1];returno},{})

//不推薦寫法
document.location.search
.replace(/(^?)/,'')
.split('&')
.reduce((searchParams,keyValuePair)=>{
keyValuePair=keyValuePair.split('=');
searchParams[keyValuePair[0]]=keyValuePair[1];
returnsearchParams;
},
{}
)

不要處理錯(cuò)誤

每次系統(tǒng)提示服務(wù)異常、服務(wù)超時(shí)，對(duì)于用戶來講，都是非常糟糕的體驗(yàn)。

大多數(shù)用戶都沒有什么耐心，總是出現(xiàn)異常，用戶可能就會(huì)破口大罵了。

所以為了用戶體驗(yàn)，絕對(duì)不要用彈框提示異常信息。

只要沒有提醒，用戶就會(huì)嘗試進(jìn)行自我解釋：懷疑自己手機(jī)壞了，或者是網(wǎng)絡(luò)不好。

對(duì)于我們的軟件，就不會(huì)有什么負(fù)面的評(píng)價(jià)啦~

同時(shí)，千萬不要把錯(cuò)誤信息記錄日志。

一個(gè)上線的運(yùn)行的系統(tǒng)出現(xiàn)故障時(shí)，程序員總是要花費(fèi)很多時(shí)間去排查錯(cuò)誤，這是一件非常勞神費(fèi)力的事情。

所以只要沒有日志文件，自然也就用不著排查問題啦。

相信我，你的同事會(huì)感謝你幫他們減少了工作量的。

//推薦寫法
try{
...
}catch(error){
//這里啥都不用處理
}

//不推薦寫法
try{
...
}catch(error){
//顯示錯(cuò)誤信息
showErrorMessage(error.message);
//記錄日志文件
logError(error);
}

創(chuàng)建不需要使用的變量

//推薦寫法
functionsum(a,b,c){
consttimeout=1300;
constresult=a+b;
returna+b;
}

//不推薦寫法
functionsum(a,b){
returna+b;
}

在代碼里多創(chuàng)建一些不需要使用的變量，這樣可以測試運(yùn)行代碼的機(jī)器極限所在。

在實(shí)踐中你會(huì)發(fā)現(xiàn)，即便是創(chuàng)建了很多的變量，服務(wù)器和客戶端都能毫不費(fèi)力的抗住壓力。

如果服務(wù)器抗不住，說明該升級(jí)服務(wù)器了。

這可是提前幫助團(tuán)隊(duì)排了雷呀，整個(gè)團(tuán)隊(duì)都會(huì)感謝你~

多使用多重嵌套

在代碼里建議使用多層的 if + for 循環(huán)等嵌套，嵌套層數(shù)越多，越能體現(xiàn)你的技術(shù)能力。

像這樣復(fù)雜的代碼，沒有較強(qiáng)的技術(shù)實(shí)力，自己寫著寫著都能蒙圈。

只有技術(shù)扎實(shí)的程序員，才能完美駕馭這樣的寫法。

所以，在工作中多寫一寫能夠體現(xiàn)自己技術(shù)實(shí)力的代碼，你才有機(jī)會(huì)肩負(fù)更大的責(zé)任。

//推薦寫法
functionsomeFunction(){
if(condition1){
if(condition2){
asyncFunction(params,(result)=>{
if(result){
for(;;){
if(condition3){
}
}
}
})
}
}
}

//不推薦寫法
asyncfunctionsomeFunction(){
if(!condition1||!condition2){
return;
}

constresult=awaitasyncFunction(params);
if(!result){
return;
}

for(;;){
if(condition3){
}
}
}

不要測試

最后一條，那就是寫完代碼之后一定不要測試。

很多程序員都有一個(gè)壞習(xí)慣，寫完代碼之后喜歡測試，甚至有些人還會(huì)測試好幾遍。

他們沒有想過，公司是有測試工程師的。

作為開發(fā)崗，居然把測試的活兒都給搶了，這不是搶別人飯碗嗎？

一旦遇上裁員，倒霉的就是這一批測試同事。

為了同事著想，是不是該把別人的活兒留給別人？

嚴(yán)格按照 只開發(fā)，不測試的方式工作， 開發(fā)的工作效率，完全能夠翻倍。

好處多多。

over ~

比較有代表性的幾條，我都幫大家列出來，沒有做到的小伙伴，請(qǐng)反思一下自己。

沒有做到第幾條，那么請(qǐng)?jiān)诤罄m(xù)的工作中嚴(yán)格執(zhí)行，糾正自己的壞習(xí)慣。

審核編輯 ：李倩