概要

JavaScriptの真偽値は「trueかfalseか」ではない。
それは**“型に依存する曖昧な変換ルールの上に成り立つ評価系”**であり、
"Truthy / Falsy の正体を理解せずに条件分岐を組むと、意図しないロジックバグを生む”。

JavaScriptは動的型付け言語であり、if文や条件演算子における「評価」は暗黙の型変換（coercion）に委ねられる。
それを安全に扱うための設計戦略と、比較演算・条件評価の明示的制御をこの記事では解説する。

1. JavaScriptにおける「Falsy」な値とは？

const falsyValues = [false, 0, -0, 0n, "", null, undefined, NaN];

✅ 上記はすべて if (value) で falseと判定される
❌ "" や 0 など、実在する値なのに「false扱い」される

2. 暗黙的 vs 明示的な条件分岐の違い

const input = "";

if (input) {
  proceed(); // ❌ 実際には空文字だが、Falsyなので通らない
}

if (input.length > 0) {
  proceed(); // ✅ 「空でない文字列」の明示的な判定
}

✅ 条件は 目的に応じて明示的に書く
✅ "存在" を問う → value != null
✅ "非空" を問う → value.length > 0

3. == vs === による型変換の影響

0 == false     // ✅ true（型変換あり）
0 === false    // ❌ false（型違い）

null == undefined  // ✅ true
null === undefined // ❌ false

✅ == は「等価」ではなく「曖昧な変換付き比較」
✅ 設計的には常に === を使うのが原則

4. 条件評価の失敗例とリファクタ戦略

function isEmpty(value) {
  return !value; // ❌ 0や""を全て弾いてしまう
}

function isEmptyString(value) {
  return typeof value === 'string' && value.length === 0;
}

✅ 判定したい対象の「意味」を明示する
❌ 型の違いや目的の曖昧化が UIバグや意図違いを生む

5. "truthy/falsyに頼らない" 条件式設計

// ❌ 暗黙の評価
if (userInput) {
  ...
}

// ✅ 明示的に書くべき設計
if (typeof userInput === 'string' && userInput.trim().length > 0) {
  ...
}

✅ 条件式には「文脈」がある → それをコードに反映
✅ "0" や "" を「ない」とみなすのは 文脈依存

設計判断フロー

① この条件分岐は「値の存在」を見ているのか？「値の中身」を見ているのか？

② 条件式の評価が文脈とズレていないか？（e.g. 0, ""）

③ == を使っていないか？（使うなら明確な理由があるか？）

④ 明示的な判定ができる設計か？（型 / 範囲 / 中身）

⑤ falsyな値を意図的に許容するなら、明文化されているか？

よくあるミスと対策

❌ `if (value)` で 0 や "" まで弾いてしまう

→ ✅ 存在確認なら value != null、中身確認なら .length や .trim()

❌ `==` を使って型の違いに気づかないままロジックが破綻

→ ✅ 原則 === / !== で明示的な比較を行う

❌ falsy判定に頼りすぎて意味の伝わらない分岐になっている

→ ✅ 条件式は「意味の名詞化 + 明示」で構造的に記述

結語

Truthy / Falsy とは「true/falseの代替」ではない。
それは**“型と構造に依存した暗黙の変換であり、設計的な意図が表現されていない限り、ロジックの罠となる”**。

比較は常に === を基本とし
存在と中身の違いを分けて記述し
条件分岐は「文脈」と「意図」を可視化する形で表現する

JavaScriptにおける真偽値判定とは、
“設計意図と型の関係を安全に可視化するための制御構造のデザインである。”