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

有一端時間，這個項目簡直火得不行~

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

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

變量名越簡單越好

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

原本需要打三個字母的時間，直接節省了 2/3 ，每天的工作效率直接爆表。

至于可讀性？

那是你一個碼農應該考慮的問題嗎？

相信我，怎么快怎么來。

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

不要寫注釋

千萬不要寫注釋，寫注釋花費的時間，都足夠你多寫好幾個功能的代碼了。

而且你想想，公司招人都會選擇技術成熟的程序員。

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

那豈不是不具備較強的讀程能力？

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

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

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

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

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

盡可能把代碼寫成一行

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

數據占用的存儲空間越小，在網絡中傳輸的速度就會越快。

在移動互聯網高速發展的今天，加快數據傳輸，絕對是能極大的提高用戶體驗的操作。

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

//推薦寫法
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;
},
{}
)

不要處理錯誤

每次系統提示服務異常、服務超時，對于用戶來講，都是非常糟糕的體驗。

大多數用戶都沒有什么耐心，總是出現異常，用戶可能就會破口大罵了。

所以為了用戶體驗，絕對不要用彈框提示異常信息。

只要沒有提醒，用戶就會嘗試進行自我解釋：懷疑自己手機壞了，或者是網絡不好。

對于我們的軟件，就不會有什么負面的評價啦~

同時，千萬不要把錯誤信息記錄日志。

一個上線的運行的系統出現故障時，程序員總是要花費很多時間去排查錯誤，這是一件非常勞神費力的事情。

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

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

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

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

創建不需要使用的變量

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

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

在代碼里多創建一些不需要使用的變量，這樣可以測試運行代碼的機器極限所在。

在實踐中你會發現，即便是創建了很多的變量，服務器和客戶端都能毫不費力的抗住壓力。

如果服務器抗不住，說明該升級服務器了。

這可是提前幫助團隊排了雷呀，整個團隊都會感謝你~

多使用多重嵌套

在代碼里建議使用多層的 if + for 循環等嵌套，嵌套層數越多，越能體現你的技術能力。

像這樣復雜的代碼，沒有較強的技術實力，自己寫著寫著都能蒙圈。

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

所以，在工作中多寫一寫能夠體現自己技術實力的代碼，你才有機會肩負更大的責任。

//推薦寫法
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){
}
}
}

不要測試

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

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

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

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

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

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

嚴格按照 只開發，不測試的方式工作， 開發的工作效率，完全能夠翻倍。

好處多多。

over ~

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

沒有做到第幾條，那么請在后續的工作中嚴格執行，糾正自己的壞習慣。

審核編輯 ：李倩