JS不要再到處使用絕對等于運(yùn)算符了
我們知道現(xiàn)在的開發(fā)人員都使用===來代替==,為什么呢?
我在網(wǎng)上看到的大多數(shù)教程都認(rèn)為,要預(yù)測JavaScript強(qiáng)制轉(zhuǎn)換是如何工作這太復(fù)雜了,因此建議總是使用===。
這些都導(dǎo)致許多程序員將該語言的一部分排除在外,并將其視為一種缺陷,而不是去擴(kuò)大他們的對該過程的理解。
下面通過兩個(gè)使用案例,說明使用==的好處。
1.測試空值if (x == null)vsif (x === undefined || x === null)2.讀取用戶的輸入
let userInput = document.getElementById(’amount’);let amount = 999;if (amount == userInput)vsif (amout === Number(userInput))
在本文中,我們將通過對比差異,理解強(qiáng)制性,研究一些流行的用例,并最終找到指導(dǎo)我們做出決定的準(zhǔn)則,來深入了解該主題。
簡介在JavaScript中,相等由兩個(gè)運(yùn)算符完成。
1.=== —嚴(yán)格相等比較也稱為三等運(yùn)算符。
2.== — 抽象的相等比較
我一直在使用===,因?yàn)槲冶桓嬷?=更好和更好,而且我根本不需要考慮它,作為一個(gè)懶惰的人,我覺得很方便。
直到我觀看了Kyle或@getfiy的You Do n’t Know JS作者在Frontend Masters上的“ Deep JavaScript Foundations”。
作為一名專業(yè)的程序員,我沒有深入思考我每天工作中使用的操作符,這一事實(shí)激勵(lì)我去傳播意識(shí),并鼓勵(lì)人們更多地理解和關(guān)注我們編寫的代碼。
事實(shí)的根源在哪里知道真實(shí)的原因在哪里很重要。 不是在 Mozilla 的 W3school 上,也不在聲稱===優(yōu)于==的數(shù)百篇文章中,而且在這篇文章中也絕對沒有。。
在JavaScript規(guī)范中,我們可以找到關(guān)于JavaScript如何工作的文檔。
打破常識(shí)1.==只檢查值(松散)如果看一下規(guī)范,從定義中可以很清楚地看出,算法要做的第一件事實(shí)際上就是檢查類型。
在這里,我們同樣可以從規(guī)范中看到,它檢查類型,如果它們不同,則不會(huì)再檢查值。
雙等號(hào)和三等號(hào)之間的真正區(qū)別是我們是否允許強(qiáng)制轉(zhuǎn)換。
JavaScript 中的強(qiáng)制轉(zhuǎn)換強(qiáng)制轉(zhuǎn)換或類型轉(zhuǎn)換是任何編程語言的基礎(chǔ)之一。 這對于動(dòng)態(tài)類型化的語言(例如JavaScript)尤為重要,因?yàn)槿绻愋透模幾g器不會(huì)對它大喊大叫,找它麻煩。
理解強(qiáng)制性意味著我們能夠以與JavaScript相同的方式解釋代碼,從而為我們提供了更大的可擴(kuò)展性并最大程度地減少了錯(cuò)誤。
顯性強(qiáng)制轉(zhuǎn)換強(qiáng)制轉(zhuǎn)換可以在程序員調(diào)用這些方法之一時(shí)顯式發(fā)生,從而強(qiáng)制改變變量的類型。
Boolean(), Number(), BigInt(), String(), Object()
事例:
let x = ’foo’;typeof x // stringx = Boolean(’foo’)typeof x // boolean隱藏轉(zhuǎn)換
在JavaScript中,變量的類型很弱,因此這意味著它們可以自動(dòng)轉(zhuǎn)換(隱式強(qiáng)制)。 當(dāng)我們使用算術(shù)運(yùn)算符+ / — *,周圍的上下文或使用==時(shí),通常是這種情況。
2 / ’3’ // ’3’ 強(qiáng)制轉(zhuǎn)為 3new Date() + 1 // 強(qiáng)制轉(zhuǎn)換為以1結(jié)尾的日期字符串if(x) // x 被強(qiáng)制為布爾值1 == true // true 被強(qiáng)制為 11 == ’true’ // ’true’ 被強(qiáng)制為 NaN`this ${variable} will be coreced to string
隱性強(qiáng)制是一把雙刃劍,合理使用可以增加可讀性,減少冗長。如果使用不當(dāng)或被誤解,我們就會(huì)有一個(gè)讓人失望的公式,人們會(huì)咆哮并指責(zé)JavaScript。
比較的算法== 運(yùn)算符號(hào)的算法
1.如果X和Y是相同的類型,則執(zhí)行===。
2.如果X為null且Y未定義或反之,則為true。
3.如果一個(gè)是數(shù)字,則將另一個(gè)強(qiáng)制為數(shù)字。
4.如果一個(gè)是對象,則強(qiáng)制轉(zhuǎn)換為原始對象。
5.其它,返回false。
=== 比較的算法
1.如果類型不匹配false。
2.如果類型匹配-比較值,為NaN時(shí)返回false。
3.-0 — true.
流行的用例1. 同類型(多數(shù)情況)如果類型相同,則===與==完全相同。因此,應(yīng)該使用語義性更強(qiáng)的那個(gè)。
1 == 1 // true......1 === 1 // true’foo’ == ’foo’ // true...... ’foo’ === ’foo’ //true
類型不同,我更喜歡用===。
2. 不同類型(原始類型)首先,我想提醒您注意,不同類型并不意味著未知類型。不知道類型表明代碼中的問題比僅使用===vs==更大。了解類型表明對代碼有更深入的理解,這會(huì)減少更多的錯(cuò)誤。
假設(shè)我們有一個(gè)數(shù)字或字符串的可能性。請記住,算法更偏向數(shù)字類型,因此它將嘗試使用toNumber()
let foo = 2;let bar = 32; // number 還是 stringfoo == bar // 如果 bar 是字符串,它會(huì)轉(zhuǎn)換成 numberfoo === Number(bar) // doing basically the samefoo === bar // 哪里 bar 為 string 則該結(jié)果為 false3. null和undefined
使用==時(shí),null和undefined彼此相等。
let foo = nulllet bar = undefined; foo == bar // truefoo === bar // false4.非原始類型[對象,數(shù)組]
不應(yīng)該使用==或===來比較對象和數(shù)組等非原始類型的數(shù)據(jù)。
決策準(zhǔn)則1.在所有可以使用的情況下,最好使用==。
2.==具有已知類型,可以選擇強(qiáng)制類型轉(zhuǎn)換。
3.知道類型總比不知道好。
4.如果不知道類型,就不要使用==。
5.當(dāng)類型不匹配時(shí),===是沒有意義的。
6.當(dāng)類型匹配時(shí),===是不必要的。
避免使用 == 情況在某些情況下,如果不真正了解JavaScript中的虛值,則不應(yīng)使用==。
== with 0 or '' or ' '== with non primtives== true or == false總結(jié)
根據(jù)我的經(jīng)驗(yàn),到目前為止,我一直都知道我要處理的變量的類型,如果我不知道,我就使用typeof來只允許我所期望的變量。
需要注意的四點(diǎn)
1.如果你不知道變量類型,那么使用===是惟一合理的選擇
2.不知道類型可能意味著你不理解代碼,請嘗試重構(gòu)你的代碼
3.知道類型可以編寫更好的代碼。
4.如果類型已知,則最好使用==。
以上就是JS不要再到處使用絕對等于運(yùn)算符了的詳細(xì)內(nèi)容,更多關(guān)于JS的資料請關(guān)注好吧啦網(wǎng)其它相關(guān)文章!
相關(guān)文章:
1. Springboot 全局日期格式化處理的實(shí)現(xiàn)2. vue實(shí)現(xiàn)web在線聊天功能3. Django使用HTTP協(xié)議向服務(wù)器傳參方式小結(jié)4. JAMon(Java Application Monitor)備忘記5. SpringBoot+TestNG單元測試的實(shí)現(xiàn)6. docker容器調(diào)用yum報(bào)錯(cuò)的解決辦法7. Java使用Tesseract-Ocr識(shí)別數(shù)字8. 完美解決vue 中多個(gè)echarts圖表自適應(yīng)的問題9. HTML基本語法和語義寫法規(guī)則與實(shí)例10. 前端獲取http狀態(tài)碼400的返回值實(shí)例
