布爾值看起來簡單，但用起來卻常常讓人頭疼。它們表面上只是“真”或“假”，但一旦深入使用，就會(huì)發(fā)現(xiàn)它們很容易引發(fā)混亂。

多年的編碼經(jīng)驗(yàn)讓我對(duì)布爾值保持警惕。也許你習(xí)慣了它們，但我發(fā)現(xiàn)，能不用就盡量不用；如果非用不可，也得格外小心。

為什么？因?yàn)椴紶栔等菀鬃屵壿嬜兊脧?fù)雜。命名糟糕、否定邏輯、嵌套條件，這些都會(huì)讓代碼變得難以理解。更糟的是，我們常常把多個(gè)布爾條件組合在一起，讓閱讀者的大腦不得不做多重判斷。

但布爾值畢竟是編程中不可或缺的一部分。因此，我總結(jié)了五條使用布爾值的規(guī)則：

保持積極 正面條件優(yōu)先 禁止復(fù)雜表達(dá)式 拒絕布爾參數(shù) 布爾值是未來復(fù)雜性的陷阱

保持積極

在處理布爾變量時(shí)，我盡量保持它們的命名是積極的，這意味著當(dāng)變量為True時(shí)，事情是正常工作和發(fā)生的。因此我更喜歡這樣的表達(dá)式：

if UserIsAuthorized {
  // 執(zhí)行某些操作
}

而不是：

if !UserIsNotAuthorized {
  // 執(zhí)行某些操作
}

前者可讀性更強(qiáng)，更容易理解。需要處理雙重否定會(huì)讓大腦感到痛苦。雙重否定意味著要思考兩件事而不是一件。

正面條件優(yōu)先

本著保持積極的精神，如果你必須使用if... else結(jié)構(gòu)，請(qǐng)將正面條件放在前面。我們的思維方式喜歡沿著"快樂路徑"前進(jìn)，所以將否定條件放在前面可能會(huì)讓人感到不適。換句話說，不要這樣做：

if not Authorized {
  // 不好的情況
} else {
  // 好的情況
}

而應(yīng)該將正面條件放在前面：

if Authorized {
  // 一切正常
} else {
  // 滾開!!
}

這樣更容易閱讀，而且你不需要處理not操作。

禁止復(fù)雜表達(dá)式

解釋性變量被嚴(yán)重低估了。我理解這一點(diǎn)——我們想要快速前進(jìn)。但停下來把事情寫清楚總是值得的，就像你的數(shù)學(xué)老師過去常說的"展示你的解題過程"。我遵循這樣的規(guī)則：只在命名變量之間使用&&和||，永遠(yuǎn)不要使用原始表達(dá)式。

我經(jīng)常看到這樣的代碼：

if (user.age > 18 && user.isActive && !user.isBanned && user.subscriptionLevel >= 2) {
  grantAccess();
}

相反，你應(yīng)該考慮那些不得不閱讀這段可怕代碼的人，并像這樣寫出來：

const isAdult = user.age > 18;
const hasAccess = !user.isBanned;
const isActive = user.isActive;
const isSubscriber = user.subscriptionLevel >= 2;

const canAccess = isAdult && hasAccess && isActive && isSubscriber;

if (canAccess) {
  grantAccess();
}

這樣可讀性極強(qiáng)，而且清楚地表明了它在做什么以及期望什么。不要害怕讓解釋性變量變得明確。我懷疑有人會(huì)抱怨：

const userHasJumpedThroughAllTheRequiredHoops = true;

我知道這需要更多的輸入，但清晰度比節(jié)省幾個(gè)按鍵要寶貴得多。此外，這些解釋性變量是單元測試的絕佳候選者。它們還使日志記錄和調(diào)試變得更加容易。

拒絕布爾參數(shù)

沒有什么比布爾參數(shù)更能讓人每分鐘產(chǎn)生更多"這到底是怎么回事？"的疑問了。看看這個(gè)例子：

saveUser(user, true, false); // 這到底意味著什么？

當(dāng)你編寫函數(shù)時(shí)，參數(shù)是有命名的，看起來沒問題。但當(dāng)你要調(diào)用它時(shí)，維護(hù)者必須查找函數(shù)聲明才能理解傳遞了什么。

相反，為什么不完全避免使用布爾值，而是聲明一個(gè)描述性的enum類型來解釋參數(shù)的作用？

enum WelcomeEmailOption {
  Send,
  DoNotSend,
}

enum VerificationStatus {
  Verified,
  Unverified,
}

然后你的函數(shù)可以這樣寫：

function saveUser(
  user: User,
  emailOption: WelcomeEmailOption,
  verificationStatus: VerificationStatus
): void {
  if (emailOption === WelcomeEmailOption.Send) {
    sendEmail(user.email, 'Welcome!');
  }
  if (verificationStatus === VerificationStatus.Verified) {
    user.verified = true;
  }
  // 保存用戶到數(shù)據(jù)庫...
}

你可以這樣調(diào)用它：

saveUser(newUser, WelcomeEmailOption.Send, VerificationStatus.Unverified);

這難道不是對(duì)大腦更友好嗎？這個(gè)調(diào)用就像文檔一樣。它清晰明了，維護(hù)者可以立即看到調(diào)用做了什么以及參數(shù)的含義。

布爾值是未來復(fù)雜性的陷阱

enum的一個(gè)優(yōu)點(diǎn)是它們可以擴(kuò)展。想象一下，你有一個(gè)食品飲料系統(tǒng)，有小型和大型飲料。你可能會(huì)得到：

var IsSmallDrink: boolean;

你圍繞這個(gè)布爾變量構(gòu)建了你的系統(tǒng)，甚至在數(shù)據(jù)庫中為這些信息創(chuàng)建了布爾字段。但后來老板過來告訴你："嘿，我們要開始賣中號(hào)飲料了！"

哦豁，這將是一個(gè)重大變更。突然間，一個(gè)簡單的布爾值變成了一個(gè)負(fù)債。但如果你避免了布爾值，而是從一開始就使用：

enum DrinkSize {
  Small,
  Large
}

那么添加另一種飲料尺寸就會(huì)容易得多。

聽著，布爾值既強(qiáng)大又簡單。我年紀(jì)足夠大，還記得語言甚至沒有布爾類型的時(shí)候。我們不得不使用整數(shù)來模擬它們：

10 LET FLAG = 0
20 IF FLAG = 1 THEN PRINT "YOU WILL NEVER SEE THIS"
30 LET FLAG = 1
40 IF FLAG = 1 THEN PRINT "NOW IT PRINTS"
50 END

所以我理解它們的吸引力。但使用布爾值最終會(huì)充滿危險(xiǎn)。有例外情況嗎？當(dāng)然有，有些簡單情況實(shí)際上就是非真即假，而且永遠(yuǎn)如此——比如isLoading。但如果你趕時(shí)間，或者放松警惕，或者可能有點(diǎn)懶惰，你很容易陷入編寫復(fù)雜、難以理解的代碼的陷阱中。所以在使用布爾變量之前，請(qǐng)謹(jǐn)慎小心。

原文地址：https://www.infoworld.com/article/3990923/booleans-considered-harmful.html
作者：Nick Hodges