概要
条件分岐とは「ifを書けば済む」ものではない。
それは**“意図・構造・流れを明確にし、読みやすさと保守性を同時に担保するための制御表現”**である。
JavaScriptにおいては if
を始め、switch
、三項演算子(?:)
、ガード節
など多様な選択肢が存在する。
しかし、それぞれには向き不向きと構造的な制約があり、誤用すると可読性と意図の伝達性が著しく低下する。
本稿では、分岐構造の設計的な整理法と選定基準を解説する。
1. 基本方針:条件は短く、明示的に、意図と一致させる
// ❌ 曖昧で読みにくい
if (x && !y || (z && !x)) { ... }
// ✅ 関数や変数で意味を明示化
const shouldShowWarning = isLoggedIn && !hasPermission;
if (shouldShowWarning) { ... }
- ✅ 条件は「名詞化された意図」で記述
- ❌ 複雑な論理をそのまま書かない
2. 三項演算子の設計的使用
// ✅ シンプルで短い代入・返却に限定
const color = isActive ? "red" : "gray";
// ❌ 複雑な処理を入れない
const result = isAdmin
? doAdminTask()
: isGuest
? doGuestTask()
: doFallback(); // ❌ ネスト構造で読みにくい
- ✅ 短く明確な選択処理に限って使う
- ❌ 分岐が増える・処理が重いときは
if
やswitch
に変える
3. switch文の戦略的使い方
switch (user.role) {
case "admin":
grantAdmin();
break;
case "editor":
grantEditor();
break;
case "viewer":
grantViewer();
break;
default:
denyAccess();
}
- ✅ 1つの値に対する複数パターンの分岐
- ✅ 条件が 固定の型や列挙子に対応するときに有効
- ❌ 条件が boolean や複雑な式なら
if
のほうが明確
4. ガード節による早期リターン戦略
function validate(user) {
if (!user) throw new Error("No user");
if (!user.token) throw new Error("No token");
// ✅ ここまで来たら処理を続行
process(user);
}
- ✅ 不要なネストを減らす
- ✅ 「正しくないものを先に排除する」構造で処理が読みやすくなる
5. if / else ではなく構造で意図を伝える
// ❌ ロジックの分岐が曖昧
if (isMember) {
if (isPremium) { showPremium(); }
else { showStandard(); }
} else {
showGuest();
}
// ✅ 構造と命名で意図を明示
if (isPremiumMember(user)) return showPremium();
if (isStandardMember(user)) return showStandard();
return showGuest();
- ✅ ネストせずに構造をフラットに
- ✅ 条件式を関数で抽象化し、文脈を明確にする
設計判断フロー
① 分岐の数は? → 3つ以上ならswitchまたは状態値に置き換え
② 条件式は短く意味が明確か? → 複雑なら関数化・変数化
③ elseが連続して深くなっていないか? → ガード節に変換
④ 条件に「型の一貫性」があるか? → 値で分岐ならswitchを選ぶ
⑤ 三項演算子は「代入・返却」に限定されているか?
よくあるミスと対策
❌ if
ネストが深くなって構造が読めなくなる
→ ✅ 早期return(ガード節)で分岐を平坦化
❌ 三項演算子の中にまた三項を入れて読みづらい
→ ✅ if文かswitch文に戻す、関数化して読みやすくする
❌ switch文のdefaultを忘れて例外条件で処理が止まる
→ ✅ defaultは明示的に書く / enumにマッチしないときの対応を必ず入れる
結語
分岐構造とは「処理の切り替え」ではない。
それは**“条件の意味と構造の明示化を通じて、意図とロジックの整合性を保つための表現戦略”**である。
-
if
は直感に、switch
は分類に、三項は簡潔に、ガード節は構造化に - すべての条件式は「意味」で語られるべき
- 分岐は「状態設計」と「流れの明示化」をセットで捉えるべき
JavaScriptにおける分岐制御とは、
“論理を伝えるために構造をデザインする制御構造戦略”である。