もう迷わない！三項演算子の「使うべき・使うべきでない」判断基準とTypeScript/React時代のベストプラクティス

「三項演算子は便利だけど、使うなと言われるのはなぜ？」

プログラミング現場でよく耳にするこの疑問、あなたも一度は感じたことがあるのではないでしょうか。

三項演算子（条件式 ? 真の場合 : 偽の場合）は、コードを短く書けて一見スマート。しかし、実際の開発現場やチーム開発では「読みにくい」「保守しづらい」「バグの温床になる」として、使用を制限する声も多く上がっています。

特にTypeScriptやReactなどのモダンな開発環境、Google JavaScript Style GuideやAirbnbスタイルガイドでも、三項演算子の使い方には明確な基準や制約が設けられています。

本記事では、三項演算子がなぜ「使うな」と言われるのか、その理由を技術的・実務的な観点から徹底解説。if文との比較や、ネスト（入れ子）による混乱、実際のバグ事例、そして代替手段やリファクタリングのベストプラクティスまで、現場で役立つ情報を具体例とともに紹介します。

「なぜ三項演算子は嫌われるのか」「どんな場面で避けるべきか」「チームでどうルール化すればいいのか」――そんな疑問を持つ方に、納得感ある答えをお届けします。

三項演算子はなぜ「使うな」と言われるのか？

プログラミングの現場で「三項演算子は使うな」という声を聞いたことがある開発者は多いでしょう。一見すると、三項演算子（条件 ? 真の場合 : 偽の場合）は簡潔でエレガントに見えるかもしれません。しかし、実際の開発現場では、この演算子が様々な問題を引き起こす可能性があります。

読みにくさの正体：三項演算子が嫌われる技術的理由

認知負荷の増大

人間の脳は情報を処理する際に、一度に扱える情報量に限界があります。三項演算子を読む際、私たちの脳は以下の処理を同時に行う必要があります：

1. 条件式の評価
2. 真の場合の処理内容の理解
3. 偽の場合の処理内容の理解
4. 全体の論理フローの把握

この複数の処理を一行で同時に行うことは、認知負荷を著しく増大させます。特に複雑な条件や多分岐が含まれる場合、この負荷は指数的に増加します。

// 認知負荷が高い例
const result = user.isAdmin ? (user.permissions.includes('write') ? 'full-access' : 'read-only') : (user.isGuest ? 'guest-access' : 'no-access');

上記のコードを初見で理解するには、複数の条件と分岐を頭の中で整理する必要があり、エラーが発生しやすくなります。

デバッグの困難さ

三項演算子を使用したコードは、デバッグ時に以下の問題を引き起こします：

1. ブレークポイントの設定が困難 一行に複数のロジックが含まれているため、特定の条件分岐にブレークポイントを設定することができません。
2. エラーの原因特定が複雑 エラーが発生した際、どの部分（条件式、真の場合の処理、偽の場合の処理）で問題が発生したのかを特定するのに時間がかかります。

// エラーの原因特定が困難
const userName = user?.profile?.name ? user.profile.name.toUpperCase() : user.email?.split('@')[0]?.toUpperCase();
// どこでエラーが発生したのか分からない

保守性の低下

三項演算子は将来的な変更や機能追加において、以下の問題を引き起こします：

1. 条件の追加が困難 新しい条件を追加する際、既存の三項演算子を大幅に書き換える必要があります。
2. ロジックの分離が困難 ビジネスロジックが一行に凝縮されているため、テストケースの作成や個別のロジックテストが困難になります。

三項演算子 vs if文：実例で見る可読性・保守性・デバッグ性の比較

シンプルなケースでの比較

三項演算子を使用した場合：

const message = isLoggedIn ? 'Welcome back!' : 'Please log in';

if-else文を使用した場合：

let message;
if (isLoggedIn) {
  message = 'Welcome back!';
} else {
  message = 'Please log in';
}

このシンプルなケースでは、三項演算子の方が簡潔で読みやすいと感じる開発者が多いでしょう。しかし、以下の観点で比較すると：

• 可読性: 三項演算子の方が簡潔だが、if文の方が意図が明確
• デバッグ性: if文の方が各分岐にブレークポイントを設定可能
• 保守性: どちらもほぼ同等

複雑なケースでの比較

三項演算子を使用した場合：

const userAccess = user.role === 'admin' ?
  (user.department === 'IT' ? 'full-system-access' : 'department-admin') :
  (user.role === 'manager' ?
    (user.permissions.includes('approve') ? 'approval-access' : 'basic-manager') :
    (user.isActive ? 'standard-user' : 'restricted-user'));

if-else文を使用した場合：

let userAccess;

if (user.role === 'admin') {
  if (user.department === 'IT') {
    userAccess = 'full-system-access';
  } else {
    userAccess = 'department-admin';
  }
} else if (user.role === 'manager') {
  if (user.permissions.includes('approve')) {
    userAccess = 'approval-access';
  } else {
    userAccess = 'basic-manager';
  }
} else {
  if (user.isActive) {
    userAccess = 'standard-user';
  } else {
    userAccess = 'restricted-user';
  }
}

複雑なケースでの比較結果：

• 可読性: if文の方が論理フローを追いやすい
• デバッグ性: if文の方が各条件にブレークポイント設定可能
• 保守性: if文の方が新しい条件追加や変更が容易

入れ子の三項演算子が引き起こす混乱とバグのリスク事例

悪いコード例とその問題点

// 悪い例1: 深いネストによる混乱
const pricing = user.isPremium ?
  (user.isYearly ?
    (user.hasDiscount ? 99.99 : 199.99) :
    (user.hasDiscount ? 9.99 : 19.99)) :
  (user.isTrial ? 0 : 4.99);

// 悪い例2: 条件の複雑化
const status = order.isPaid ?
  (order.isShipped ?
    (order.isDelivered ? 'completed' : 'in-transit') :
    (order.isProcessing ? 'processing' : 'confirmed')) :
  (order.isCancelled ? 'cancelled' : 'pending-payment');

実際のバグシナリオ

シナリオ1: 条件の見落とし

// 意図: 管理者または所有者のみアクセス許可
const canAccess = user.isAdmin ? true : user.isOwner ? true : false;

// 実際の問題: user.isOwnerがundefinedの場合の処理が不明瞭
// 期待する動作と実際の動作が異なる可能性

シナリオ2: 優先順位の誤解

// 意図した動作と異なる結果になりやすい
const discount = age > 65 ? 0.2 : income < 30000 ? 0.1 : hasCard ? 0.05 : 0;
// 複数の条件の組み合わせで、期待しない結果が生じる

チーム開発への影響

入れ子の三項演算子は、チーム開発において以下の問題を引き起こします：

1. コードレビューの負荷増大

• レビュアーが論理フローを理解するのに時間がかかる
• 見落としやすいバグの温床となる
• 条件の追加や変更時の影響範囲が分かりにくい

2. 認識齟齬の発生

• 開発者間でコードの意図についての解釈が分かれる
• 新しいメンバーのオンボーディングが困難
• ドキュメント化が難しく、暗黙知に依存しやすい

3. メンテナンス性の悪化

• 機能追加時の変更箇所が広範囲に及ぶ
• テストケースの作成が困難
• リファクタリング時のリスクが高い

このように、三項演算子、特に入れ子になった三項演算子は、一見すると簡潔で洗練されているように見えますが、実際の開発現場では多くの問題を引き起こす可能性があります。次のセクションでは、これらの問題を解決するための具体的な代替手段とリファクタリング方法について詳しく解説します。

三項演算子の代替手段とリファクタリング実践例

前セクションで三項演算子の問題点を理解したところで、実際にどのような代替手段があるのか、そしてどのようにリファクタリングすれば良いのかを具体的に見ていきましょう。ここでは実践的なテクニックと、実際の開発現場で使える具体例を豊富に紹介します。

三項演算子を使わない書き方：if文・ガード句・関数分割のベストプラクティス

if-else文への書き換え実例

複雑な三項演算子の例：

// 三項演算子を使った複雑な例
const userMessage = user.isLoggedIn ?
  (user.hasNotifications ?
    `Welcome back, ${user.name}! You have ${user.notifications.length} new notifications.` :
    `Welcome back, ${user.name}!`) :
  'Please log in to continue.';

if-else文に書き換えた例：

let userMessage;

if (!user.isLoggedIn) {
  userMessage = 'Please log in to continue.';
} else if (user.hasNotifications) {
  userMessage = `Welcome back, ${user.name}! You have ${user.notifications.length} new notifications.`;
} else {
  userMessage = `Welcome back, ${user.name}!`;
}

この書き換えにより、以下の改善が得られます：

• 各条件分岐が明確に分離されている
• デバッグ時に特定の条件にブレークポイントを設定できる
• 新しい条件を追加する際の影響範囲が明確

ガード句（早期リターン）の活用

ガード句は、異常系や特別なケースを早期に処理することで、メインロジックをシンプルに保つ手法です。

三項演算子を使った例：

function calculateDiscount(user, product) {
  return user ?
    (user.isPremium ?
      (product.isOnSale ? product.price * 0.3 : product.price * 0.2) :
      (product.isOnSale ? product.price * 0.1 : 0)) :
    0;
}

ガード句を使った改善例：

function calculateDiscount(user, product) {
  // ガード句で異常系を早期リターン
  if (!user) return 0;
  if (!product) return 0;

  // メインロジックをシンプルに
  if (user.isPremium) {
    return product.isOnSale ? product.price * 0.3 : product.price * 0.2;
  }

  return product.isOnSale ? product.price * 0.1 : 0;
}

関数分割による可読性向上

肥大化した条件分岐は、意味のある関数に分割することで大幅に改善できます。

分割前：

const accessLevel = user.role === 'admin' ?
  (user.department === 'security' ? 'FULL_ACCESS' :
   user.department === 'hr' ? 'HR_ACCESS' : 'ADMIN_ACCESS') :
  (user.role === 'manager' ?
    (user.teamSize > 10 ? 'SENIOR_MANAGER' : 'MANAGER') :
    (user.isActive ? 'USER' : 'GUEST'));

関数分割後：

function determineAccessLevel(user) {
  if (user.role === 'admin') {
    return getAdminAccessLevel(user);
  }

  if (user.role === 'manager') {
    return getManagerAccessLevel(user);
  }

  return getStandardAccessLevel(user);
}

function getAdminAccessLevel(user) {
  switch (user.department) {
    case 'security': return 'FULL_ACCESS';
    case 'hr': return 'HR_ACCESS';
    default: return 'ADMIN_ACCESS';
  }
}

function getManagerAccessLevel(user) {
  return user.teamSize > 10 ? 'SENIOR_MANAGER' : 'MANAGER';
}

function getStandardAccessLevel(user) {
  return user.isActive ? 'USER' : 'GUEST';
}

TypeScriptやReactで使える代替構文（??, ||, オプショナルチェイニング）

Nullish Coalescing (??) の活用

Nullish Coalescing演算子は、nullやundefinedの場合のみデフォルト値を返すため、三項演算子よりも安全で意図が明確です。

三項演算子を使った例：

const userName = user.name !== null && user.name !== undefined ? user.name : 'Anonymous';
const userAge = user.age !== null && user.age !== undefined ? user.age : 0;

Nullish Coalescing を使った改善例：

const userName = user.name ?? 'Anonymous';
const userAge = user.age ?? 0;

重要な違い：

// Logical OR (||) の場合 - falsy値すべてでデフォルト値を使用
const result1 = user.score || 100; // score が 0 の場合も 100 になる

// Nullish Coalescing (??) の場合 - null/undefined のみデフォルト値を使用
const result2 = user.score ?? 100; // score が 0 の場合は 0 のまま

オプショナルチェイニング (?.) の活用

オプショナルチェイニングは、ネストされたオブジェクトのプロパティアクセスを安全に行うための構文です。

三項演算子を使った例：

const city = user && user.address && user.address.city ? user.address.city : 'Unknown';
const firstHobby = user && user.hobbies && user.hobbies.length > 0 ? user.hobbies[0] : null;

オプショナルチェイニングを使った改善例：

const city = user?.address?.city ?? 'Unknown';
const firstHobby = user?.hobbies?.[0] ?? null;

Reactコンポーネントでの活用例

三項演算子を使った複雑な例：

function UserProfile({ user }) {
  return (
    <div>
      <h1>{user ? (user.name ? user.name : 'No Name') : 'Guest'}</h1>
      <p>{user ? (user.profile ? (user.profile.bio ? user.profile.bio : 'No bio available') : 'No profile') : 'Please log in'}</p>
      <img src={user ? (user.avatar ? user.avatar.url : '/default-avatar.png') : '/guest-avatar.png'} alt="avatar" />
    </div>
  );
}

改善されたコンポーネント：

function UserProfile({ user }) {
  const displayName = user?.name ?? 'Guest';
  const biography = user?.profile?.bio ?? (user ? 'No bio available' : 'Please log in');
  const avatarUrl = user?.avatar?.url ?? (user ? '/default-avatar.png' : '/guest-avatar.png');

  return (
    <div>
      <h1>{displayName}</h1>
      <p>{biography}</p>
      <img src={avatarUrl} alt="avatar" />
    </div>
  );
}

三項演算子からのリファクタリング事例集

事例1: ユーザー認証ロジックのリファクタリング

Before（三項演算子使用）：

function checkUserPermission(user, resource) {
  return user ?
    (user.isActive ?
      (user.role === 'admin' ? true :
       user.role === 'moderator' ? resource.type !== 'sensitive' :
       user.permissions.includes(resource.id) ? true : false) :
      false) :
    false;
}

After（構造化された条件分岐）：

function checkUserPermission(user, resource) {
  // ガード句で早期リターン
  if (!user || !user.isActive) {
    return false;
  }

  // 管理者は全てのリソースにアクセス可能
  if (user.role === 'admin') {
    return true;
  }

  // モデレーターは機密情報以外にアクセス可能
  if (user.role === 'moderator') {
    return resource.type !== 'sensitive';
  }

  // 一般ユーザーは明示的な権限が必要
  return user.permissions.includes(resource.id);
}

改善点の解説：

• ガード句により異常系を早期に処理
• 各ロールの権限チェックが独立した条件として明確化
• 新しいロールの追加が容易
• テストケースの作成が簡単

事例2: UIの表示切り替えロジック

Before（ネストした三項演算子）：

function getButtonStyle(status, isEnabled, theme) {
  return status === 'loading' ?
    { backgroundColor: '#ccc', cursor: 'not-allowed' } :
    status === 'error' ?
      { backgroundColor: '#f44336', color: 'white' } :
      status === 'success' ?
        { backgroundColor: '#4caf50', color: 'white' } :
        isEnabled ?
          (theme === 'dark' ?
            { backgroundColor: '#333', color: 'white' } :
            { backgroundColor: '#2196f3', color: 'white' }) :
          { backgroundColor: '#ccc', cursor: 'not-allowed' };
}

After（オブジェクトマップとガード句）：

function getButtonStyle(status, isEnabled, theme) {
  // ステータス別のスタイル定義
  const statusStyles = {
    loading: { backgroundColor: '#ccc', cursor: 'not-allowed' },
    error: { backgroundColor: '#f44336', color: 'white' },
    success: { backgroundColor: '#4caf50', color: 'white' }
  };

  // ステータスが指定されている場合は対応するスタイルを返す
  if (statusStyles[status]) {
    return statusStyles[status];
  }

  // 無効状態の場合
  if (!isEnabled) {
    return { backgroundColor: '#ccc', cursor: 'not-allowed' };
  }

  // 通常状態（テーマ別）
  return theme === 'dark'
    ? { backgroundColor: '#333', color: 'white' }
    : { backgroundColor: '#2196f3', color: 'white' };
}

事例3: データ整形処理のリファクタリング

Before（複雑な三項演算子）：

function formatUserData(rawUser) {
  return {
    id: rawUser.id,
    name: rawUser.firstName ?
      (rawUser.lastName ?
        `${rawUser.firstName} ${rawUser.lastName}` :
        rawUser.firstName) :
      (rawUser.email ? rawUser.email.split('@')[0] : 'Unknown User'),
    email: rawUser.email || 'no-email@example.com',
    age: rawUser.birthDate ?
      (new Date().getFullYear() - new Date(rawUser.birthDate).getFullYear()) :
      null,
    status: rawUser.isActive ?
      (rawUser.isVerified ? 'active' : 'pending') :
      'inactive'
  };
}

After（関数分割と明確な処理）：

function formatUserData(rawUser) {
  return {
    id: rawUser.id,
    name: formatUserName(rawUser),
    email: rawUser.email || 'no-email@example.com',
    age: calculateAge(rawUser.birthDate),
    status: determineUserStatus(rawUser)
  };
}

function formatUserName(user) {
  if (user.firstName && user.lastName) {
    return `${user.firstName} ${user.lastName}`;
  }

  if (user.firstName) {
    return user.firstName;
  }

  if (user.email) {
    return user.email.split('@')[0];
  }

  return 'Unknown User';
}

function calculateAge(birthDate) {
  if (!birthDate) return null;

  const birth = new Date(birthDate);
  const today = new Date();

  return today.getFullYear() - birth.getFullYear();
}

function determineUserStatus(user) {
  if (!user.isActive) return 'inactive';
  return user.isVerified ? 'active' : 'pending';
}

思考プロセスの解説：

1. 問題の特定: 一つの関数に複数の責任が混在している
2. 責任の分離: 名前の整形、年齢の計算、ステータスの決定を個別の関数に分離
3. 可読性の向上: 各関数の目的が明確になり、テストが容易
4. 拡張性の確保: 新しい整形ルールや計算ロジックの追加が容易

これらのリファクタリング事例を通じて、三項演算子を使った複雑な条件分岐を、より保守しやすく理解しやすいコードに変換する方法を学ぶことができます。次のセクションでは、チーム開発でこれらの原則をどのように統一し、運用していくかについて詳しく見ていきます。

チーム開発で三項演算子をどう扱うべきか

個人開発とは異なり、チーム開発では複数の開発者が同じコードベースを扱います。三項演算子の使用に関するルールを明確にし、ツールを活用して自動化することで、チーム全体のコード品質を向上させることができます。このセクションでは、実際のチーム運営で使える具体的な方法を紹介します。

ESLint・Prettierで自動化！三項演算子の使用を制限する設定例

ESLintによる三項演算子の制限設定

ESLintを使用することで、三項演算子の使用を自動的にチェックし、チーム全体でルールを統一できます。

基本的な制限設定（.eslintrc.js）：

module.exports = {
  "extends": ["eslint:recommended"],
  "rules": {
    // 三項演算子の使用を警告
    "no-ternary": "warn",

    // ネストした三項演算子を禁止
    "no-nested-ternary": "error",

    // 複数行にわたる三項演算子を制限
    "multiline-ternary": ["error", "never"],

    // 条件式の複雑さを制限
    "complexity": ["error", { "max": 10 }]
  }
};

より柔軟な設定例：

module.exports = {
  "extends": ["eslint:recommended"],
  "rules": {
    // ネストした三項演算子のみ禁止（シンプルな三項演算子は許可）
    "no-nested-ternary": "error",

    // 条件式が複雑な場合は警告
    "complexity": ["warn", { "max": 8 }],

    // 一行あたりの最大長を制限（長い三項演算子を間接的に制限）
    "max-len": ["error", {
      "code": 100,
      "ignoreComments": true,
      "ignoreUrls": true
    }],

    // 関数の長さを制限（複雑な条件分岐を関数分割に誘導）
    "max-lines-per-function": ["warn", { "max": 50 }]
  }
};

TypeScript専用の設定：

module.exports = {
  "extends": [
    "eslint:recommended",
    "@typescript-eslint/recommended"
  ],
  "rules": {
    "no-nested-ternary": "error",

    // TypeScript特有のルール
    "@typescript-eslint/prefer-nullish-coalescing": "error",
    "@typescript-eslint/prefer-optional-chain": "error",

    // 明示的な戻り値の型指定を推奨（三項演算子の型推論問題を回避）
    "@typescript-eslint/explicit-function-return-type": "warn"
  }
};

Prettierによるフォーマット設定

Prettierは三項演算子のフォーマットを統一し、可読性を向上させます。

prettier.config.js設定例：

module.exports = {
  // 三項演算子の改行を制御
  printWidth: 80,

  // 三項演算子を複数行に分割する際の設定
  tabWidth: 2,
  useTabs: false,

  // セミコロンとクォートの統一
  semi: true,
  singleQuote: true,

  // 末尾カンマの設定
  trailingComma: 'es5',

  // オブジェクトリテラルの波括弧内にスペースを追加
  bracketSpacing: true
};

CI/CDパイプラインへの組み込み

GitHub Actions設定例（.github/workflows/code-quality.yml）：

name: Code Quality Check

on: [push, pull_request]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2

      - name: Setup Node.js
        uses: actions/setup-node@v2
        with:
          node-version: '18'

      - name: Install dependencies
        run: npm ci

      - name: Run ESLint
        run: npm run lint

      - name: Check Prettier formatting
        run: npm run format:check

      - name: Run type check (TypeScript)
        run: npm run type-check

package.json のスクリプト設定：

{
  "scripts": {
    "lint": "eslint src/**/*.{js,ts,tsx} --max-warnings 0",
    "lint:fix": "eslint src/**/*.{js,ts,tsx} --fix",
    "format": "prettier --write src/**/*.{js,ts,tsx}",
    "format:check": "prettier --check src/**/*.{js,ts,tsx}",
    "type-check": "tsc --noEmit"
  }
}

関数化・早期return・null合体演算子など代替テクニック5選

1. 関数化による責任の分離

// 変更前：複雑な三項演算子
const message = user.isVip ?
  (user.points > 1000 ? 'Gold VIP Member' : 'Silver VIP Member') :
  (user.isRegistered ? 'Welcome Member' : 'Guest User');

// 変更後: 関数化
function getUserWelcomeMessage(user) {
  if (user.isVip) {
    return getVipMessage(user);
  }

  return user.isRegistered ? 'Welcome Member' : 'Guest User';
}

function getVipMessage(user) {
  return user.points > 1000 ? 'Gold VIP Member' : 'Silver VIP Member';
}

const message = getUserWelcomeMessage(user);

2. 早期return（ガード句）パターン

// 変更前: ネストした三項演算子
function calculateShippingCost(order, user) {
  return order ?
    (order.total > 100 ? 0 :
     user && user.isPremium ? 5 : 10) :
    null;
}

// 変更後: 早期return
function calculateShippingCost(order, user) {
  if (!order) return null;
  if (order.total > 100) return 0;
  if (user?.isPremium) return 5;

  return 10;
}

3. オブジェクトリテラル/Mapを使った条件分岐

// 変更前: 複数の三項演算子
const getStatusColor = (status) => {
  return status === 'active' ? '#4caf50' :
         status === 'pending' ? '#ff9800' :
         status === 'error' ? '#f44336' :
         status === 'disabled' ? '#9e9e9e' : '#000000';
};

// 変更後: オブジェクトリテラル
const STATUS_COLORS = {
  active: '#4caf50',
  pending: '#ff9800',
  error: '#f44336',
  disabled: '#9e9e9e'
};

const getStatusColor = (status) => {
  return STATUS_COLORS[status] ?? '#000000';
};

// Mapを使用する場合（より動的な用途に適している）
const statusColorMap = new Map([
  ['active', '#4caf50'],
  ['pending', '#ff9800'],
  ['error', '#f44336'],
  ['disabled', '#9e9e9e']
]);

const getStatusColor = (status) => {
  return statusColorMap.get(status) ?? '#000000';
};

4. 短絡評価（&&, ||）の活用

// 変更前: 三項演算子での存在チェック
const renderUserInfo = (user) => {
  return user ?
    (user.name ? `<span>${user.name}</span>` : '') :
    '';
};

// 変更後: 短絡評価
const renderUserInfo = (user) => {
  return user?.name && `<span>${user.name}</span>`;
};

// 複数の条件での活用
const canEdit = user && user.isActive && user.permissions.includes('edit');
const defaultValue = userInput || config.defaultValue || 'N/A';

5. Null合体演算子とオプショナルチェイニングの組み合わせ

// 変更前: 複雑な存在チェック
const getUserDisplayInfo = (user) => {
  return {
    name: user && user.profile && user.profile.displayName ?
          user.profile.displayName :
          (user && user.email ? user.email : 'Anonymous'),
    avatar: user && user.profile && user.profile.avatar ?
            user.profile.avatar.url : '/default-avatar.png',
    lastSeen: user && user.lastLoginAt ?
              new Date(user.lastLoginAt).toLocaleDateString() :
              'Never'
  };
};

// 変更後: モダンな構文
const getUserDisplayInfo = (user) => {
  return {
    name: user?.profile?.displayName ?? user?.email ?? 'Anonymous',
    avatar: user?.profile?.avatar?.url ?? '/default-avatar.png',
    lastSeen: user?.lastLoginAt ? new Date(user.lastLoginAt).toLocaleDateString() : 'Never'
  };
};

Google JavaScript Style GuideやAirbnbスタイルに見る三項演算子の扱い

Google JavaScript Style Guide の方針

Google JavaScript Style Guideでは、三項演算子について以下のガイドラインを定めています：

Google JavaScript Style Guide

google.github.io

推奨事項：

• シンプルな条件分岐では三項演算子の使用を許可
• ネストした三項演算子は禁止
• 複雑な条件式は if-else 文を使用することを推奨

具体的なルール：

// Good: シンプルな三項演算子
const result = condition ? value1 : value2;

// Bad: ネストした三項演算子
const result = condition1 ?
  (condition2 ? value1 : value2) :
  value3;

// Good: if-else文での代替
let result;
if (condition1) {
  result = condition2 ? value1 : value2;
} else {
  result = value3;
}

Airbnb JavaScript Style Guide の方針

Airbnb Style Guideは、より厳格なアプローチを取っています：

GitHub - airbnb/javascript: JavaScript Style Guide

JavaScript Style Guide. Contribute to airbnb/javascript development by creating an account on GitHub.

github.com

主要なルール：

• 多段階の三項演算子は禁止 (eslint: no-nested-ternary)
• 三項演算子は単一行で使用することを推奨
• 複雑な条件は関数に分割することを強く推奨

ESLint設定例：

// Airbnb推奨設定
{
  "extends": ["airbnb-base"],
  "rules": {
    "no-nested-ternary": "error",
    "no-unneeded-ternary": "error",
    "operator-linebreak": ["error", "before"]
  }
}

その他の主要スタイルガイドの比較

Microsoft TypeScript Coding Guidelines：

• TypeScript特有の型推論問題を避けるため、複雑な三項演算子の使用を非推奨
• Null合体演算子(??)とオプショナルチェイニング(?.)の使用を強く推奨

Vue.js Style Guide：

• テンプレート内での複雑な三項演算子を禁止
• 算出プロパティ(computed)やメソッドでの処理を推奨

Coding guidelines

TypeScript is a superset of JavaScript that compiles to clean JavaScript output. - microsoft/TypeScript

github.com

スタイルガイド — Vue.js

Vue.js - The Progressive JavaScript Framework

v2.ja.vuejs.org

チーム用スタイルガイド策定のアドバイス

1. プロジェクトの特性を考慮した設定

// スタートアップ・アジャイル開発向け（柔軟性重視）
{
  "rules": {
    "no-nested-ternary": "warn",  // 警告レベル
    "complexity": ["warn", 8]
  }
}

// エンタープライズ・長期運用向け（厳格性重視）
{
  "rules": {
    "no-nested-ternary": "error", // エラーレベル
    "no-ternary": "warn",         // 三項演算子自体を警告
    "complexity": ["error", 5]
  }
}

2. チーム合意形成のプロセス

## チーム内でのスタイルガイド策定手順

1. **現状分析**: 既存コードベースの三項演算子使用状況を調査
2. **問題点の共有**: 実際に発生した保守性・可読性の問題を具体例で共有
3. **ルール案の作成**: 段階的な導入計画を含むルール案を作成
4. **試用期間の設定**: 2-4週間の試用期間で運用テスト
5. **フィードバック収集**: チームメンバーからの意見を収集・調整
6. **正式導入**: CI/CDパイプラインへの組み込みと完全運用開始

3. 教育・オンボーディング戦略

• コードレビューでの指導: 具体例を示しながらの建設的なフィードバック
• ペアプログラミング: 経験豊富なメンバーとの共同作業による学習
• 勉強会の開催: チーム内での知識共有セッション
• ドキュメント化: 判断基準とコード例を含む内部ドキュメントの作成

これらのアプローチにより、チーム全体で一貫性のあるコード品質を維持し、新しいメンバーも迷うことなく開発に参加できる環境を構築することができます。権威あるスタイルガイドを参考にしつつ、チームの実情に合わせたカスタマイズを行うことが成功の鍵となります。

よくある質問（FAQ）

まとめ

この記事では「三項演算子 使うな」という一見すると極端にも思えるキーワードの裏側に隠された、コード品質とチーム開発における奥深い理由を探ってきました。単に「使うな」と言われることには、実は明確な技術的・実践的な根拠があることをご理解いただけたのではないでしょうか。

三項演算子は、適切に使えばコードを簡潔にする強力なツールです。しかし、その手軽さゆえに、可読性を著しく損ねるリスクも同時に持ち合わせています。特に、以下のようなケースでは注意が必要です。

• 複雑な条件式や多重な入れ子：コードが読みにくくなり、意図しないバグの温床になりがちです。
• デバッグの困難さ：一行に詰め込みすぎたロジックは、問題発生時の原因特定を難しくします。
• チーム開発での認識齟齬：メンバー間の解釈のずれが、思わぬ手戻りや品質低下を招くことがあります。

そして、これらの課題を解決するために、私たちは具体的な代替手段とリファクタリングのプラクティスをご紹介しました。

• if-else文やガード句：複雑な条件分岐も、これらを使えば明確かつ安全に記述できます。
• 関数分割：ロジックを小さな関数に切り出すことで、各部分の役割が明確になり、再利用性も高まります。
• TypeScriptの構文（??、?.など）：現代のJavaScript開発では、これらの新しい構文が三項演算子をより安全かつ簡潔に置き換える強力な選択肢となります。
• ESLintやスタイルガイドの活用：チーム全体でコードの品質を担保するためには、自動化されたリンターやGoogle、Airbnbのような信頼できるスタイルガイドの導入が不可欠です。

コードは一度書いたら終わりではありません。むしろ、そこから始まる「保守」と「改善」こそが開発の大部分を占めます。そのためには、誰が読んでも理解しやすい、バグを生まないコードを目指すことが何よりも重要です。三項演算子を使うかどうかの判断は、最終的には「そのコードがどれだけ読みやすく、将来にわたってメンテナンスしやすいか」という視点に集約されます。

この記事が、皆さんの日々のコーディングやチームでの議論に役立ち、より高品質で持続可能なソフトウェア開発の一助となれば幸いです。

JavaScriptでキャッシュをクリアする方法【完全ガイド】

はじめにWeb開発を行っていると、変更を加えたはずのJavaScriptファイルがブラウザにキャッシュされていて、意図した動作にならないことがあります。この記事では、JavaScriptを使用してキャッシュをクリアする方法を詳しく解説します。キャッシュの仕組みや、各種ブラウザでのキャッシュクリア手順についても紹介するの...

watashi.xyz

2025.02.25

JavaScriptのドット3つ（...）とは？スプレッド構文を徹底解説

1. はじめにJavaScriptを学んでいると、...（ドット3つ）という記号を目にすることがあります。これは「スプレッド構文（Spread Syntax）」または「レスト構文（Rest Syntax）」と呼ばれ、配列やオブジェクトの操作を簡潔に記述できる便利な機能です。本記事では、JavaScriptのスプレッド構...

watashi.xyz

2025.02.06