前言
過(guò)去，我寫(xiě)了很多垃圾代碼，現(xiàn)在看起來(lái)很糟糕。
當(dāng)我再次看到那些代碼片段時(shí)，我什至懷疑自己是否適合做程序員。
所以，這里有 10 個(gè)我總結(jié)的JavaScript 技巧，可以幫助你避免編寫(xiě)我曾經(jīng)做過(guò)的那種垃圾代碼。
1. Promise 回調(diào)地獄
Promise 提供了一種優(yōu)雅的方式來(lái)處理 JavaScript 中的異步操作。這也是避免“回調(diào)地獄”的解決方案之一。但是我并沒(méi)有真正理解它的含義，所以我寫(xiě)了這個(gè)代碼片段。
我做了這些事情：
- 首先獲取用戶的基本信息。
- 按用戶信息獲取所有文章的簡(jiǎn)要摘要。
- 通過(guò)文章簡(jiǎn)要獲取文章詳細(xì)信息。
// ?getUserInfo()(userInfo) => getArticles(userInfo)(articles) => Promise.all(articles.map((article) =>(articleDetails) => console.log(articleDetails) }) }) })
我根本沒(méi)有在這里利用 Promise，我們應(yīng)該像下面的代碼片段一樣處理它：
// ?getUserInfo() .then((getArticles)(articles) => return Promise.all(articles.map((article) => })(articleDetails) => console.log(articleDetails) })
2.不處理錯(cuò)誤信息
我經(jīng)常只寫(xiě)成功請(qǐng)求的代碼邏輯，而忽略請(qǐng)求失敗。
// ?const getUserInfo = async () => { try { const userInfo = await fetch('/api/getUserInfo') } catch (err) {
}}這是沒(méi)有經(jīng)驗(yàn)的，我們應(yīng)該給出一個(gè)用戶友好的提示，而不是什么都不做。
// ?const getUserInfo = async () => { try { const userInfo = await fetch('/api/getUserInfo') } catch (err) { Toast(err.message) }}3. 給一個(gè)函數(shù)設(shè)置太多參數(shù)
當(dāng)一個(gè)函數(shù)的參數(shù)太多時(shí)，它的可讀性就會(huì)降低，甚至，讓我們想知道如何正確傳遞參數(shù)。
例子
我們想要獲取用戶的一些基本信息，比如姓名、性別、年齡等。
// ?const getUserInfo = (name, age, weight, gender, mobile , nationality, hobby, address) => // ...}getUserInfo('fatfish', 100, 2000, ...)那太糟了，如果你的同事這樣寫(xiě)代碼，你會(huì)揍他嗎？
事實(shí)上，當(dāng)函數(shù)參數(shù)過(guò)多時(shí)，應(yīng)該使用對(duì)象來(lái)傳遞需要的信息，這樣它的可讀性和可擴(kuò)展性都會(huì)得到提高。
// ?const getUserInfo = (options) => const { name, gender, age, mobile, weight, nationality, hobby, address } = options // ...}getUserInfo({name: 'fatfish',age: 100,weight: 2000 // ...})4.Magic number
朋友們，你們寫(xiě)過(guò)這樣的代碼嗎？在很多地方使用數(shù)字進(jìn)行邏輯判斷似乎很正常。是的，它讓我感到困惑 1、2、3 到底是什么意思。
?// component1.jsif (status === 1 || status === 2) { // ...} else if (status === 3) { // ...}// component2.jsif (status === 1 || status === 2) { // ...}我們最好將這些數(shù)字定義為常數(shù)。
// ?// constants.jsexport const STATUS = { // It is an adult and has real-name authentication adultRealName: 1, // It is a minor and has real-name authentication minorRealName: 2, // Not real-name authentication notRealName: 3, // ...}// component1.jsimport { STATUS } from './constants.js'if ([ STATUS.adultRealName, STATUS.minorRealName ].includes(status)) { // ...} else if (status === STATUS.notRealName) { // ...}// component2.jsimport { STATUS } from './constants.js'// component2.jsif ([ STATUS.adultRealName, STATUS.minorRealName ].includes(status)) { // ...}5.使用.length判斷字符串的長(zhǎng)度
大多數(shù)情況下，我們使用 .length 來(lái)判斷字符串的長(zhǎng)度是安全的，但在表單輸入的情況下要小心。
當(dāng)我們輸入 ?? 時(shí)，nameLen 的值為 2——這不是很奇怪嗎？
// ?<input type="text" id="name"><script> const $name = document.getElementById('name') $name.addEventListener('blur', () => { const name = $name.value const nameLen = name.length // input: fatfish => nameLen: 7 // input: ?? => nameLen: 2 console.log(`name: ${name}, nameLen: ${nameLen}`) }, false)</script>是的，這是有原因的，你猜怎么著？
// ?<input type="text" id="name"><script> const $name = document.getElementById('name') $name.addEventListener('blur', () => { const name = $name.value const nameLen = name.length const spRegexp = /[\uD800-\uDBFF][\uDC00-\uDFFF]/g const nameRealLen = name.replace(spRegexp, '_').length // input: fatfish => nameLen: 7, nameRealLen: 7 // input: ?? => nameLen: 2, nameRealLen: 1 console.log(`name: ${name}, nameLen: ${nameLen}, nameRealLen: ${nameRealLen}`) }, false)</script>
6.永遠(yuǎn)不要寫(xiě)代碼注釋
我們經(jīng)常向別人抱怨，“你為什么不寫(xiě)代碼注釋?zhuān)俊?但實(shí)際上，我自己也從來(lái)沒(méi)有寫(xiě)過(guò)注釋?zhuān)?/p>
// ?const fn = (dpr) => if (dpr >= 2) { // ... } else { }}天哪，你知道'dpr'是什么意思嗎？ 我從沒(méi)想過(guò)它的意思是窗口設(shè)備PixelRatio。
// ?// dpr: Please enter a value for window.devicePixelRatioconst fn = (dpr) => if (dpr >= 2) { // ... } else { }}7. 無(wú)意義的代碼注釋
與其不寫(xiě)代碼注釋?zhuān)膊灰獙?xiě)無(wú)意義的代碼注釋?zhuān)驗(yàn)檫@會(huì)浪費(fèi)你的時(shí)間。
你不妨解釋一下“a”的含義或使用有意義的變量名！
// ?let a = 1 // Set the value of "a" to 1
8.隨機(jī)命名
過(guò)去，我曾經(jīng)編寫(xiě)過(guò)隨機(jī)命名變量的笨拙代碼片段。
朋友，請(qǐng)不要向我學(xué)習(xí)，你應(yīng)該給變量一個(gè)適當(dāng)且有意義的名稱(chēng)。
9.不要?jiǎng)h除不推薦使用的代碼
很多時(shí)候，我們的網(wǎng)站會(huì)不斷的調(diào)整功能，有新的和棄用的功能，但我總是擔(dān)心我以后會(huì)用到，所以我只是評(píng)論它們，而不是刪除它們。
其實(shí)，這種擔(dān)心是完全沒(méi)有必要的，因?yàn)橐院笥玫目赡苄院苄 ?就算以后會(huì)用到，也可以通過(guò)‘git’來(lái)追溯。
10. 超過(guò)一千行的組件代碼
我在一個(gè)組件中編寫(xiě)了超過(guò)一千行代碼。 這太糟糕了，我們應(yīng)該將組件的功能進(jìn)一步拆分為更小的組件。
寫(xiě)在最后
這些都是我工作的一些經(jīng)驗(yàn)總結(jié)，希望這篇文章內(nèi)容對(duì)你有所幫助。
