ルール
検出 矛盾 または 不可能な 論理
コード が 条件 条件 後に  
確認する 違反 違反された後、 あるいは 仮定する 州が
が 状態 不可能 与えられた その 制御 フロー。

サポート言語: 45+

はじめに

矛盾したロジックは、コードが先行する制御フローに基づいて既に真または偽と判明している条件をチェックする際に発生する。これはリファクタリング後に検証処理の順序が変更された場合や、開発者が既存の保証内容を理解せずに防御的チェックを追加した場合に生じる。例えば、既に真と判明している条件をチェックする関数は矛盾したロジックとなる。 if (user !== null) 電話した後 ユーザーメールアドレス 矛盾した論理構造を持ち、NULLチェックが実施されるタイミングが遅すぎる。こうした論理的不可能性は、コード構成の根本的な問題や、各コード分岐が保証する内容に対する理解不足を示している。

なぜそれが重要なのか

セキュリティ上の影響：誤った検証は安全という危険な錯覚を生み出す。データが既に使用された後にセキュリティチェックが行われる場合、攻撃者は検証が行われるまでの隙間を悪用できる。特権操作を実行した後にユーザー権限を検証するコードは、実際の保護を提供せず、セキュリティに関する誤解を招くコメントでしかない。

コードの保守性：矛盾したロジックは、コードが開発者のメンタルモデルと一致していないことを示唆する。誰かが条件チェックが必要だと考えたが配置を誤ったか、関連するチェックを更新せずにコードがリファクタリングされた可能性がある。将来の保守担当者は必要な箇所に検証が存在するとは信頼できず、実際の保証を理解するために関数全体を追跡せざるを得なくなる。

バグの兆候：不可能な状態は単独で発生することは稀です。これらは、エラー処理の欠如、関数契約に関する誤った前提、リファクタリングの失敗といった根本的な問題を示しています。決して実行されないチェックは、この状態を未然に防ぐべき別のチェックがどこかで欠落していることを意味することが多いのです。

コード例

非準拠：

function processOrder(order) {
    if (!order) {
        return { error: 'Order required' };
    }

    const total = order.items.reduce(
        (sum, item) => sum + item.price,
        0
    );

    if (order.items && order.items.length > 0) {
        applyDiscount(order);
    }

    if (total < 0) {
        throw new Error('Invalid total');
    }

    return { total, status: 'processed' };
}

なぜそれが間違っているのか： コードは呼び出します order.items.reduce() アイテムが null または 未定義その後、アイテムが存在するかどうかを確認します。 total < 0 チェックは矛盾している。なぜなら、価格を合計する際、reduceは常に非負の値を返すからだ。

✅ 準拠：

function processOrder(order) {
    if (!order || !order.items || order.items.length === 0) {
        return { error: 'Valid order with items required' };
    }

    const hasInvalidPrice = order.items.some(
        item => typeof item.price !== 'number' || item.price < 0
    );

    if (hasInvalidPrice) {
        throw new Error('Invalid item prices');
    }

    const total = order.items.reduce(
        (sum, item) => sum + item.price,
        0
    );

    if (order.items.length >= 5) {
        applyBulkDiscount(order);
    }

    return { total, status: 'processed' };
}

これが重要な理由：すべての検証はデータ使用前に実行され、チェックは論理的な順序で行われ、条件は実際の要件を反映しています。この関数は事前に入力を検証し、その後、冗長または矛盾するチェックなしに有効なデータを処理します。

結論

データ使用前に検証を配置し、使用後に行わないこと。防御的と思われる条件でも、データが既にアクセスまたは変更された後に現れるものは見直せ。リファクタリング時には、関数全体の論理的整合性を維持するため、関連する検証を更新または削除せよ。