前兩天看到一則代碼注釋里出現各種臟話的消息,這讓我想起了之前看過的一個很有意思的開源項目。
有一段時間,這個項目簡直火得不行~
教你怎樣寫出不被同事罵的代碼。
項目一共列出了 20 條建議之多,這里月亮挑幾條最有意思的分享出來。
變量名越簡單越好
比如,變量名用 a 替代 age。
原本需要打三個字母的時間,直接節省了 2/3 ,每天的工作效率直接爆表。
至于可讀性?
那是你一個碼農應該考慮的問題嗎?
相信我,怎么快怎么來。
//推薦寫法
let a = 42;
//不推薦寫法
let age = 42;
不要寫注釋
千萬不要寫注釋,寫注釋花費的時間,都足夠你多寫好幾個功能的代碼了。
而且你想想,公司招人都會選擇技術成熟的程序員。
沒有注釋就看不懂代碼了?
那豈不是不具備較強的讀程能力?
你不寫注釋,我認為沒有問題,如果你的同事真的讀不懂,說明他需要反思自己的專業能力了。
記住啦,千萬不要寫注釋,要相信你的同事~
ps:寫到這里,突然想起一個段子。
每個程序員最討厭做的事情:寫注釋。
每個程序員最討厭其他程序員做的事情:不寫注釋。
盡可能把代碼寫成一行
把代碼寫成一行,可以減少不必要的存儲空間消耗。
數據占用的存儲空間越小,在網絡中傳輸的速度就會越快。
在移動互聯網高速發展的今天,加快數據傳輸,絕對是能極大的提高用戶體驗的操作。
所以,盡量把代碼寫成一行,好處非常多。
//推薦寫法
document.location.search.replace(/(^?)/,'').split('&').reduce(function(o,n){n=n.split('=');o[n[0]]=n[1];return o},{})
//不推薦寫法
document.location.search
.replace(/(^?)/, '')
.split('&')
.reduce((searchParams, keyValuePair) => {
keyValuePair = keyValuePair.split('=');
searchParams[keyValuePair[0]] = keyValuePair[1];
return searchParams;
},
{}
)
不要處理錯誤
每次系統提示服務異常、服務超時,對于用戶來講,都是非常糟糕的體驗。
大多數用戶都沒有什么耐心,總是出現異常,用戶可能就會破口大罵了。
所以為了用戶體驗,絕對不要用彈框提示異常信息。
只要沒有提醒,用戶就會嘗試進行自我解釋:懷疑自己手機壞了,或者是網絡不好。
對于我們的軟件,就不會有什么負面的評價啦~
同時,千萬不要把錯誤信息記錄日志。
一個上線的運行的系統出現故障時,程序員總是要花費很多時間去排查錯誤,這是一件非常勞神費力的事情。
所以只要沒有日志文件,自然也就用不著排查問題啦。
相信我,你的同事會感謝你幫他們減少了工作量的。
// 推薦寫法
try {
...
} catch (error) {
// 這里啥都不用處理
}
// 不推薦寫法
try {
...
} catch (error) {
//顯示錯誤信息
showErrorMessage(error.message);
// 記錄日志文件
logError(error);
}
創建不需要使用的變量
//推薦寫法
function sum(a, b, c) {
const timeout = 1300;
const result = a + b;
return a + b;
}
//不推薦寫法
function sum(a, b) {
return a + b;
}
在代碼里多創建一些不需要使用的變量,這樣可以測試運行代碼的機器極限所在。
在實踐中你會發現,即便是創建了很多的變量,服務器和客戶端都能毫不費力的抗住壓力。
如果服務器抗不住,說明該升級服務器了。
這可是提前幫助團隊排了雷呀,整個團隊都會感謝你~
多使用多重嵌套
在代碼里建議使用多層的 if + for 循環等嵌套,嵌套層數越多,越能體現你的技術能力。
像這樣復雜的代碼,沒有較強的技術實力,自己寫著寫著都能蒙圈。
只有技術扎實的程序員,才能完美駕馭這樣的寫法。
所以,在工作中多寫一寫能夠體現自己技術實力的代碼,你才有機會肩負更大的責任。
//推薦寫法
function someFunction() {
if (condition1) {
if (condition2) {
asyncFunction(params, (result) => {
if (result) {
for (;;) {
if (condition3) {
}
}
}
})
}
}
}
//不推薦寫法
async function someFunction() {
if (!condition1 || !condition2) {
return;
}
const result = await asyncFunction(params);
if (!result) {
return;
}
for (;;) {
if (condition3) {
}
}
}
不要測試
最后一條,那就是寫完代碼之后一定不要測試。
很多程序員都有一個壞習慣,寫完代碼之后喜歡測試,甚至有些人還會測試好幾遍。
他們沒有想過,公司是有測試工程師的。
作為開發崗,居然把測試的活兒都給搶了,這不是搶別人飯碗嗎?
一旦遇上裁員,倒霉的就是這一批測試同事。
為了同事著想,是不是該把別人的活兒留給別人?
嚴格按照 只開發,不測試的方式工作, 開發的工作效率,完全能夠翻倍。
好處多多。
over ~
比較有代表性的幾條,我都幫大家列出來,沒有做到的小伙伴,請反思一下自己。
沒有做到第幾條,那么請在后續的工作中嚴格執行,糾正自己的壞習慣。
最后
這些非常良好的習慣,我被打進醫院之前,就是這樣做的,你們且看且珍惜!
原文:
https://mp.weixin.qq.com/s/NkLw3g5-Bx_ET4vxAnBtYg