資訊專欄INFORMATION COLUMN
摘要：本文章記錄本人在深入學(xué)習(xí)條件表達(dá)式中看書理解到的一些東西，并且整理記錄下來，加深記憶和方便之后的復(fù)習(xí)。表達(dá)式的值具有線性特征，如對(duì)連續(xù)的區(qū)間值進(jìn)行判斷。
本文章記錄本人在深入學(xué)習(xí)js條件表達(dá)式中看書理解到的一些東西，并且整理記錄下來，加深記憶和方便之后的復(fù)習(xí)。主要是深入學(xué)習(xí)if else和switch語句的一些性能優(yōu)化和邏輯思維。
提高條件性能的策略js的條件表達(dá)式和其他語言一樣，都采用了if else和switch這兩種。由于不同的瀏覽器對(duì)流程控制進(jìn)行了不同的優(yōu)化。因此這兩種在性能上是沒有什么區(qū)別的，主要還是根據(jù)需求進(jìn)行分析和選擇。
如果條件較小的話選用if else比較合適。
相反，條件數(shù)量較大的話，就建議選用switch。
一般來說，if else適用于兩個(gè)離散的值或者不同的值域。如果判斷多個(gè)離散值，使用switch更加合適。
恰當(dāng)?shù)氖褂?if 與 switch在大多數(shù)的情況下switch比if else運(yùn)行的更加快。
當(dāng)我們使用到條件表達(dá)式的時(shí)候，無論if else還是switch，都應(yīng)確保下面3個(gè)目標(biāo)的基本實(shí)現(xiàn)：
精確表現(xiàn)事物的內(nèi)在、固有的邏輯關(guān)系。不能為了結(jié)構(gòu)而破壞。
優(yōu)化邏輯的執(zhí)行效率。執(zhí)行效率是程序設(shè)計(jì)的重要目標(biāo)，不能為了省事而隨意的消耗資源。
簡(jiǎn)化代碼的結(jié)構(gòu)層次，使代碼更加容易的閱讀。
適合使用if else的情況：
具有復(fù)雜的邏輯關(guān)系。
表達(dá)式的值具有線性特征，如對(duì)連續(xù)的區(qū)間值進(jìn)行判斷。
表達(dá)式的值是動(dòng)態(tài)的。
測(cè)試任意類型的數(shù)據(jù)。
適合使用switch的情況：
每句表達(dá)式的值。這種是可以期望的、平行邏輯關(guān)系的。
表達(dá)式的值具有離散性，不具有線性的非連續(xù)的區(qū)間值。
表達(dá)式的值是固定的，不是動(dòng)態(tài)變化的。
表達(dá)式的值是有限的，而不是無限的，一般情況下表達(dá)式應(yīng)該比較少。
表達(dá)式的值一般為整數(shù)、字符串類型的數(shù)據(jù)。
例如，對(duì)學(xué)生的分?jǐn)?shù)進(jìn)行不同的判斷，這個(gè)時(shí)候使用if else就比較合適，因?yàn)檫@種情況，表達(dá)式的值是連續(xù)的線性判斷。
Javascriptif (socre < 60) {
alert("不及格");
} else if (socre > 60 && socre <= 85) {
alert("良好");
} else if (socre > 86) {
alert("優(yōu)秀");
}
而判斷性別之類的使用switch就比較合適。
Javascriptswitch (sex) {
case "男":
alert("先生");
break;
case "女":
alert("女士");
break;
}
優(yōu)化 if 邏輯
邏輯順序體現(xiàn)了人的思維的條理和嚴(yán)密性。合理的順序可以提升解決問題的品質(zhì)，相反，混亂的順序和容易導(dǎo)致各種錯(cuò)誤的發(fā)生。
人們考慮的東西到時(shí)候，都會(huì)把最可能發(fā)生的情況先做好準(zhǔn)備。優(yōu)化if邏輯的時(shí)候也可以這樣想：把最可能出現(xiàn)的條件放在前面，把最不可能出現(xiàn)的條件放在后面，這樣程序執(zhí)行時(shí)總會(huì)按照帶啊名的先后順序逐一檢測(cè)所有的條件，知道發(fā)現(xiàn)匹配的條件才會(huì)停止繼續(xù)檢測(cè)。
if的優(yōu)化目標(biāo)：最小化找到分支之前所判斷條件體的數(shù)量。if優(yōu)化的方法：將最常見的條件放在首位。
Javascriptif (i < 5) {
// 執(zhí)行一些代碼
} else if (i > 5 && i < 10) {
// 執(zhí)行一些代碼
} else {
// 執(zhí)行一些代碼
}
例如上面這個(gè)例子，只有在i值經(jīng)常出現(xiàn)小于5的時(shí)候是最優(yōu)化的。如果i值經(jīng)常大于或者等于10的話，那么在進(jìn)入正確的分支之前，就必須兩次運(yùn)算條件體，導(dǎo)致表達(dá)式的平均運(yùn)算時(shí)間增加。if中的條件體應(yīng)該總是按照從最大概率到最小概率排列，以保證理論速度最快。
if 嵌套的思維陷阱在if語句里面在嵌套一個(gè)if語句是一件經(jīng)常見到的東西，假設(shè)有4個(gè)調(diào)價(jià)你，只有當(dāng)這些條件都符合要求的時(shí)候，才會(huì)執(zhí)行某一些事情。遵循一般人的思維習(xí)慣，在檢測(cè)這些條件的時(shí)候，常常會(huì)沿用下面這種結(jié)構(gòu)嵌套：
Javascriptif (a) {
if (b) {
if (c) {
if (d) {
alert("條件全部成立");
} else {
alert("條件 d 不成立");
}
} else {
alert("條件 c 不成立");
}
} else {
alert("條件 b 不成立");
}
} else {
alert("條件 a 不成立");
}
從思維的方向性來考慮，這種結(jié)構(gòu)并沒有錯(cuò)，使用下面這種if結(jié)構(gòu)來表示可能更加的合適和簡(jiǎn)單：
Javascriptif (a && b && c && d) {
alert("全部條件成立");
}
從剛才的代碼來說，使用if語句來逐個(gè)驗(yàn)證條件的合法性，并且對(duì)某個(gè)條件是否合法進(jìn)行了提示，方便我們?nèi)プ粉櫭恳粋€(gè)條件。但是，如果使用了上面的if結(jié)構(gòu)多重嵌套，就會(huì)出現(xiàn)另一種可能：a條件如果不成立的話，就會(huì)直接跳出整個(gè)嵌套結(jié)構(gòu)，不會(huì)去管b，c，d條件是否成立。如果這樣做的話，層層包裹的if結(jié)構(gòu)會(huì)使代碼嵌套過深，難以編輯。
為了解決上面的問題，一般來說會(huì)采用排除法，即對(duì)每一個(gè)條件進(jìn)行排除，條件全部成立在執(zhí)行特定的操作。
Javascriptvar t = true;
if (!a) {
t = false;
}
if (!b) {
t = false;
}
if (!c) {
t = false;
}
if (!d) {
t = false;
}
if (t) {
// 條件全部符合要求
}
排除法有效的避免了上面所說的條件結(jié)構(gòu)的多重嵌套問題，且更加符合人的思維模式。當(dāng)然，也存在一些局限性，一旦發(fā)生錯(cuò)誤的話，就要放棄后面的操作。如果想要防止這類問題發(fā)生，可以在設(shè)計(jì)一個(gè)標(biāo)示變量來跟蹤整個(gè)操作行為。
容易在 if 里犯的小錯(cuò)誤不知道大家有木有犯過下面這種錯(cuò)誤：
Javascript// 第一種
if (i = 1) {
alert(i);
}
// 第二種
if (i = 1) ;
{
alert(i);
}
第一種情況是，有時(shí)候會(huì)把比較運(yùn)算=== or ==符錯(cuò)寫為賦值運(yùn)算符=。而且這種錯(cuò)誤一般很難發(fā)現(xiàn)，由于它是一個(gè)合法的表達(dá)式，不會(huì)導(dǎo)致編譯錯(cuò)誤。
最后就把常量放在左邊，把變量放在右邊，這樣寫的話，就算你把=當(dāng)作了===來使用也會(huì)報(bào)錯(cuò)。
Javascriptif (1 === i) {
alert(i);
}
第二種是，在if的括號(hào)后面加了個(gè)分號(hào)，導(dǎo)致整個(gè)結(jié)構(gòu)的邏輯就發(fā)生了變化。我們應(yīng)該牢記條件表達(dá)式之后不允許添加分化，最后就通過把大括號(hào)與條件表達(dá)式寫在一行來防止犯錯(cuò)。
Javascriptif (i) {
alert(i);
}
編寫 switch 要注意的地方
千萬不要忘記在每一個(gè)case語句后面放一個(gè)break語句。也可以放一個(gè)return或者throw。case語句匹配expression是用===而不是==。
防止 switch 貫穿在switch語句中，除非明確地中斷流程，否則每次條件判斷后就會(huì)貫穿到下一個(gè)case條件。在執(zhí)行switch語句中，js會(huì)先計(jì)算switch條件的值，然后使用這個(gè)值與每個(gè)case中的值進(jìn)行比較，如果相同則執(zhí)行標(biāo)簽下的語句。在執(zhí)行的時(shí)候如果遇到跳轉(zhuǎn)語句，就會(huì)跳出switch結(jié)構(gòu)，否則就會(huì)按照順序執(zhí)行下去，知道switch語句末尾。如果沒有匹配的case的話就會(huì)執(zhí)行default的語句。
Javascriptswitch (a = 3) {
case 3 - 2:
alert(1);
break;
case 1 + 1:
alert(2);
break;
}
上面的switch語句中，case語句只是指明了想要執(zhí)行代碼的起點(diǎn)，并沒有指明終點(diǎn)，如果沒有在case從句中添加break語句，則會(huì)發(fā)生連續(xù)貫穿現(xiàn)象，從而忽略后面的case從句，這樣就會(huì)造成switch結(jié)構(gòu)的邏輯混亂。
最后，如果文章有什么錯(cuò)誤和疑問的地方，請(qǐng)指出。與sf各位共勉！
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://systransis.cn/yun/85630.html
摘要：遞歸函數(shù)還會(huì)受到瀏覽器調(diào)用棧的大小的限制。雖然迭代也會(huì)導(dǎo)致性能問題，但是使用優(yōu)化的循環(huán)就可以代替長(zhǎng)時(shí)間運(yùn)行的遞歸函數(shù)，可以提高新能，因?yàn)檫\(yùn)行一個(gè)循環(huán)比反復(fù)調(diào)用一個(gè)函數(shù)的開銷要小。 本文章記錄本人在深入學(xué)習(xí)js循環(huán)中看書理解到的一些東西，加深記憶和并且整理記錄下來，方便之后的復(fù)習(xí)。 選擇正確的循環(huán)體 在大部分編程語言中，代碼執(zhí)行的時(shí)間多數(shù)消耗在循環(huán)的執(zhí)行上。 js定義了4種...
摘要：正則表達(dá)式使用單個(gè)字符串來描述匹配一系列匹配某個(gè)句法規(guī)則的字符串。接下來，是在手機(jī)正則里面已經(jīng)出現(xiàn)了。序列匹配而則匹配。分組與反向引用分組，又稱為子表達(dá)式。把正則表達(dá)式拆分成小表達(dá)式。 本文轉(zhuǎn)載自網(wǎng)絡(luò)。轉(zhuǎn)載編輯過程中，可能有遺漏或錯(cuò)誤，請(qǐng)以原文為準(zhǔn)。原文作者：水墨寒湘原文鏈接：https://juejin.im/post/582dfc... 正則表達(dá)式對(duì)于我來說一直像黑暗魔法一樣的存...
摘要：等同于等同于其他類型和布爾類型之間的比較如果是布爾類型，則返回的結(jié)果。 showImg(https://segmentfault.com/img/bVburFq?w=796&h=398); 前言 JavaScript作為一門弱類型語言，我們?cè)诿刻斓木帉懘a過程中，無時(shí)無刻不在應(yīng)用著值類型轉(zhuǎn)換，但是很多時(shí)候我們只是在單純的寫，并不曾停下腳步去探尋過值類型轉(zhuǎn)換的內(nèi)部轉(zhuǎn)換規(guī)則，最近通過閱讀你...
摘要：等同于等同于其他類型和布爾類型之間的比較如果是布爾類型，則返回的結(jié)果。 showImg(https://segmentfault.com/img/bVburFq?w=796&h=398); 前言 JavaScript作為一門弱類型語言，我們?cè)诿刻斓木帉懘a過程中，無時(shí)無刻不在應(yīng)用著值類型轉(zhuǎn)換，但是很多時(shí)候我們只是在單純的寫，并不曾停下腳步去探尋過值類型轉(zhuǎn)換的內(nèi)部轉(zhuǎn)換規(guī)則，最近通過閱讀你...
摘要：等同于等同于其他類型和布爾類型之間的比較如果是布爾類型，則返回的結(jié)果。 showImg(https://segmentfault.com/img/bVburFq?w=796&h=398); 前言 JavaScript作為一門弱類型語言，我們?cè)诿刻斓木帉懘a過程中，無時(shí)無刻不在應(yīng)用著值類型轉(zhuǎn)換，但是很多時(shí)候我們只是在單純的寫，并不曾停下腳步去探尋過值類型轉(zhuǎn)換的內(nèi)部轉(zhuǎn)換規(guī)則，最近通過閱讀你...
閱讀 3516·2021-11-15 11:38
閱讀 836·2021-11-08 13:27
閱讀 2250·2021-07-29 14:50
閱讀 2977·2019-08-29 13:06
閱讀 848·2019-08-29 11:22
閱讀 2419·2019-08-29 11:04
閱讀 3510·2019-08-28 18:23
閱讀 896·2019-08-26 13:46
