/anti-defensive

name: anti-defensive
description: Review common AI slops of defensive programming patterns, avoid silent errors. TRIGGER when reviewing code for defensive anti-patterns, writing fail-fast code, or auditing error handling quality.

Anti-Defensive Programming Guide

Philosophy

AI coding assistants systematically over-produce defensive code due to:

• **Training data bias** — Web/app code dominates GitHub, where graceful degradation IS correct
• **RLHF reinforcement** — Humans penalize crashes more than silent incorrectness

The result: code that swallows errors, fabricates data, and fails silently instead of failing fast.

**Fail-fast principle**: Internal errors should crash immediately and loudly. Problems get fixed instead of hidden. Systems that fail fast actually have fewer outages because they are honest about what can go wrong.

**When defensive IS correct**: At system boundaries handling external input (APIs, user forms, file uploads). Internal code should trust contracts and crash on violations.

Anti-Patterns

1. Swallowing Exceptions

# BAD — Error buried, pipeline continues with None
try:
    result = transform(data)
except Exception as e:
    logger.warning(f"Transform failed: {e}")
    result = None

# GOOD — Let it fail
result = transform(data)

Harm: Downstream code receives `None`, causing JOIN failures or corrupted data. Monitoring shows "fine" because no exceptions were thrown.

2. Dictionary Defaults on Required Fields

# BAD — Fabricates data for missing required field
user_id = record.get('user_id', -1)
amount = record.get('amount', 0.0)

# GOOD — Required fields should error if missing
user_id = record['user_id']
amount = record['amount']

Harm: The `-1` user_id joins with user tables, returns nothing, analytics silently show zero activity.

3. Null Coalescing to Fabricate Data

# BAD — Invisible default, hides missing data
email = record.get('email') or 'no-email@example.com'
price = data.get('price') or 0.0

# GOOD — Explicit handling
email = record['email']  # Required
price = record.get('price')  # Nullable is intentional
if price is None:
    price = calculate_default_price(record)

Harm: The `or` operator makes defaults invisible. If a default is needed, make it explicit and documented.

4. Type Coercion Instead of Validation

# BAD — Silently converts wrong type, hides upstream bug
age = int(record.get('age', 0))
price = float(str(record.get('price', '0.0')))

# GOOD — Let type mismatches surface
age = record['age']
assert isinstance(age, int), f"Expected int, got {type(age)}"

Harm: Type mismatches indicate upstream problems. Coercing them hides the root cause.

5. Compatibility Shims

# BAD — Turns temporary debt into permanent debt
try:
    result = new_api_call(params)
except AttributeError:
    result = old_api_call(params)

# GOOD — Force migration
result = new_api_call(params)

Harm: Breaking changes remain undetected. Technical debt compounds.

6. Unnecessary Null Checks

# BAD — Misleading; type contract guarantees non-null
if user is not None and user.name is not None:
    return user.name

# GOOD — Trust the contract
return user.name

Harm: Readers assume the value can be null. Checks multiply across codebase.

7. Catch-All Exception Handlers

# BAD — Catches KeyboardInterrupt, SystemExit, MemoryError
try:
    process(data)
except:
    pass

# GOOD — Catch specific exceptions or let them propagate
try:
    process(data)
except ValidationError as e:
    raise ValueError(f"Invalid data: {e}") from e

Harm: Catches things no programmer should handle. Masks real problems.

8. Over-Validation at Internal Boundaries

# BAD — Validates what caller already guarantees
def process(data):
    if data is None:
        return None
    if not isinstance(data, dict):
        return None
    if 'id' not in data:
        return None
    return transform(data['id'])

# GOOD — Validate once at boundary, trust internally
def process(data: dict) -> Result:
    """Expects data with 'id' key. Validated at API boundary."""
    return transform(data['id'])

Harm: Validation logic duplicates across call chain. Returns `None` instead of surfacing contract violations.

9. Fabricated Default Values

# BAD — Corrupts data with fake values
created_at = record.get('created_at', datetime.now())
name = record.get('name', '')
status = record.get('status', 'unknown')

# GOOD — Required fields must be present
created_at = record['created_at']
name = record['name']
status = record.get('status')  # Only if nullable by design

Harm: Historical records get current timestamps. Empty names break downstream logic. 'unknown' status corrupts analytics.

10. Logging Warnings Instead of Raising

# BAD — Warnings are ignored
logger.warning(f"Unexpected state: {state}")
continue

# GOOD — Errors demand attention
raise ValueError(f"Unexpected state: {state}")

Harm: Problems remain undetected until they cascade into larger failures.

When Defensive IS Correct

Defensive programming is appropriate at **system boundaries**:

• **External input validation** — API payloads, form submissions, file uploads
• **User-facing error messages** — Graceful UX for invalid user actions
• **Transient failures** — Network timeouts, rate limits, temporary resource unavailability
• **Public libraries** — Cannot control caller behavior

Internal code should trust contracts and fail fast on violations.

Quick Reference

| Pattern | Anti-Pattern | Correct Approach | |---------|--------------|------------------| | Exception handling | `except Exception: pass` | Let it crash or catch specific | | Dict access | `d.get('required', default)` | `d['required']` | | Null coalescing | `x or fake_value` | Explicit `if None` logic | | Type coercion | `int(d.get('x', 0))` | Let type errors surface | | Compatibility | `try: new except: