Bad Shortcuts Anti-Patterns — Find the Bug¶

Category: Development Anti-Patterns → Bad Shortcuts — convenience taken now, paid back many times later. Covers (collectively): Copy-Paste Programming · Magic Numbers / Strings · Hard Coding · Cargo Cult Programming · Pokémon Exception Handling · Stringly-Typed Programming

This file is critical-reading practice. Each snippet below is a plausible chunk of real-world code in Go, Java, or Python. Read it the way a sharp reviewer does and answer three questions:

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

Bad shortcuts are different from bad structure. A shortcut rarely makes the code ugly enough to fail review on sight — that's the danger. Worse, for this family the "bug" is frequently a real functional or security defect that the shortcut directly causes or hides: a fix applied to one copy-pasted twin but not the other; a swallowed exception that corrupts state in silence; a hard-coded secret committed to git; a magic number that's off by a digit; a stringly-typed comparison broken by one wrong character. Several snippets here contain a live bug — your job is to find it and name the shortcut that let it through.

A few snippets are deliberately innocent: code that looks like a shortcut but is actually the right call. Critical reading means resisting the reflex to pattern-match on shape. Read slowly, write your own answer, then open the collapsible.

How to use this file: decide your verdict before expanding the answer. The skill is noticing the shortcut and tracing its consequence — not recalling the name.

Table of Contents¶

1. The two refund paths
2. Session timeout
3. Connecting to the database
4. The role check
5. The notebook that loads data
6. The order processor that never fails
7. The webhook handler
8. Two validators that drifted apart
9. The retry wrapper
10. The state machine in strings
11. The price formatter
12. The config loader
13. The event tag field
14. The cache TTLs

Snippet 1 — The two refund paths¶

# Python — two endpoints that both refund an order, written months apart
def refund_full(order):
    if order.status not in ("paid", "shipped"):
        raise ValueError("not refundable")
    amount = order.subtotal + order.tax + order.shipping        # refund everything
    gateway.refund(order.payment_id, amount)
    order.status = "refunded"
    db.save(order)

def refund_partial(order, amount):
    if order.status not in ("paid", "shipped"):
        raise ValueError("not refundable")
    # NOTE: copied from refund_full and adjusted for partial amount
    gateway.refund(order.payment_id, amount)
    order.status = "refunded"
    db.save(order)

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

def _refund(order, amount):
    if order.status not in ("paid", "shipped"):
        raise ValueError("not refundable")
    gateway.refund(order.payment_id, amount)
    order.refunded_total += amount
    order.status = "refunded" if order.refunded_total >= order.total else "partially_refunded"
    db.save(order)

def refund_full(order):           _refund(order, order.total)
def refund_partial(order, amt):   _refund(order, amt)

Snippet 2 — Session timeout¶

// Java — session expiry check in an auth filter
public boolean isExpired(Session s) {
    long now = System.currentTimeMillis();
    long ageSeconds = (now - s.getCreatedAtMillis()) / 1000;
    return ageSeconds > 8640;   // expire after one day
}

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

static final long SECONDS_PER_DAY = 86_400L;
static final long SESSION_TTL_SECONDS = SECONDS_PER_DAY;   // one day

public boolean isExpired(Session s) {
    long ageSeconds = (System.currentTimeMillis() - s.getCreatedAtMillis()) / 1000;
    return ageSeconds > SESSION_TTL_SECONDS;
}

Snippet 3 — Connecting to the database¶

// Go — service startup
package main

func newDB() (*sql.DB, error) {
    // TODO: move to config before launch
    dsn := "postgres://svc_user:Pr0d_P@ss_2023@db.internal.acme.com:5432/orders?sslmode=require"
    return sql.Open("postgres", dsn)
}

func newRedis() *redis.Client {
    return redis.NewClient(&redis.Options{Addr: "10.2.0.14:6379"})
}

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

func newDB() (*sql.DB, error) {
    dsn := os.Getenv("DATABASE_URL")          // injected per environment
    if dsn == "" {
        return nil, errors.New("DATABASE_URL is required")
    }
    return sql.Open("postgres", dsn)
}

func newRedis() *redis.Client {
    return redis.NewClient(&redis.Options{Addr: os.Getenv("REDIS_ADDR")})
}

Snippet 4 — The role check¶

// Java — authorization helper used across the admin panel
public class Access {
    public static boolean canManageUsers(User user) {
        return user.getRole().equals("Admin");
    }
}

// elsewhere, when an account is created:
void createAccount(SignupForm form) {
    User u = new User();
    u.setRole(form.isAdminRequest() ? "admin" : "member");   // lower-case here
    repo.save(u);
}

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

enum Role { ADMIN, MEMBER }

public static boolean canManageUsers(User user) {
    return user.getRole() == Role.ADMIN;
}

u.setRole(form.isAdminRequest() ? Role.ADMIN : Role.MEMBER);

Snippet 5 — The notebook that loads data¶

# Python — a data-prep function, lifted from a Stack Overflow answer
import warnings
import pandas as pd

def load_dataset(path):
    warnings.filterwarnings("ignore")          # "to make the output clean"
    df = pd.read_csv(path)
    df = df.copy()                             # "avoids SettingWithCopyWarning"
    pd.set_option("mode.chained_assignment", None)   # silence the same warning
    df = df.fillna(0).fillna(0)                # run it twice "just to be safe"
    return df.reset_index(drop=True)

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

def load_dataset(path):
    df = pd.read_csv(path)
    return df.fillna(0).reset_index(drop=True)

Snippet 6 — The order processor that never fails¶

# Python — background worker that processes a queue of orders
def process_order(order_id):
    try:
        order = db.get(order_id)
        reserve_inventory(order)
        charge_customer(order)
        mark_paid(order)
        send_confirmation_email(order)
    except:                       # make sure one bad order never kills the worker
        pass

def worker_loop():
    for order_id in queue:
        process_order(order_id)

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

def process_order(order_id):
    order = db.get(order_id)
    try:
        with db.transaction():            # money + state change atomically
            reserve_inventory(order)
            charge_customer(order)
            mark_paid(order)
    except PaymentDeclined as e:
        log.warning("payment declined", order_id=order_id, reason=e.reason)
        mark_failed(order, e.reason)      # explicit, recorded outcome
        return
    except TransientError as e:
        log.error("transient failure, will retry", order_id=order_id, exc_info=e)
        raise                              # let the queue retry; don't swallow
    send_confirmation_email(order)         # outside the txn; safe to retry separately

Snippet 7 — The webhook handler¶

// Go — receives payment webhooks from a third party
func handleWebhook(w http.ResponseWriter, r *http.Request) {
    body, _ := io.ReadAll(r.Body)
    var evt PaymentEvent
    json.Unmarshal(body, &evt)            // parse the event

    if evt.Type == "payment_succeeded" {
        markOrderPaid(evt.OrderID)
    }
    w.WriteHeader(200)
}

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

func handleWebhook(w http.ResponseWriter, r *http.Request) {
    body, err := io.ReadAll(r.Body)
    if err != nil {
        http.Error(w, "read error", http.StatusBadRequest)
        return
    }
    if !verifySignature(r.Header.Get("X-Signature"), body, webhookSecret) {
        http.Error(w, "invalid signature", http.StatusUnauthorized)   // reject forgeries
        return
    }
    var evt PaymentEvent
    if err := json.Unmarshal(body, &evt); err != nil {
        http.Error(w, "bad payload", http.StatusBadRequest)           // 4xx → sender retries
        return
    }
    if evt.Type == "payment_succeeded" {
        if err := markOrderPaid(evt.OrderID); err != nil {
            http.Error(w, "processing error", http.StatusInternalServerError) // 5xx → retry
            return
        }
    }
    w.WriteHeader(http.StatusOK)
}

Snippet 8 — Two validators that drifted apart¶

// Java — email validation, copy-pasted into two layers over time
class SignupController {
    boolean validEmail(String e) {
        return e != null && e.contains("@") && e.contains(".") && e.length() <= 254;
    }
}

class NewsletterService {
    boolean validEmail(String e) {
        // copied from SignupController, then a security fix was added HERE only
        if (e == null || e.length() > 254) return false;
        if (e.contains("\n") || e.contains("\r")) return false;   // block header injection
        return e.contains("@") && e.contains(".");
    }
}

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

final class EmailRules {                    // single source of truth
    static boolean isValid(String e) {
        if (e == null || e.length() > 254) return false;
        if (e.contains("\n") || e.contains("\r")) return false;   // header injection guard
        return e.contains("@") && e.contains(".");
    }
}

// both call sites:
boolean validEmail(String e) { return EmailRules.isValid(e); }

Snippet 9 — The retry wrapper¶

# Python — wraps a flaky upstream call with retries
import time

def call_with_retry(fn):
    for attempt in range(3):
        try:
            return fn()
        except Exception as e:
            time.sleep(2 ** attempt)        # exponential backoff
            last = e
    raise last

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

RETRIABLE = (ConnectionError, TimeoutError)      # transient, network-level only

def call_with_retry(fn, attempts=3):
    for attempt in range(attempts):
        try:
            return fn()
        except RETRIABLE as e:
            if attempt == attempts - 1:
                raise
            time.sleep(2 ** attempt)
        # ValueError, bugs, fatal errors: NOT caught — they surface immediately

Snippet 10 — The state machine in strings¶

# Python — order lifecycle managed via a string field
def advance(order):
    if order.state == "pending":
        order.state = "confirmed"
    elif order.state == "confirmed":
        order.state = "shipped"
    elif order.state == "shipped":
        order.state = "delivered"

def can_cancel(order):
    return order.state in ("pending", "confirmd")     # cancel before it ships

def is_active(order):
    return order.state != "Delivered"

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

from enum import Enum

class State(Enum):
    PENDING = "pending"
    CONFIRMED = "confirmed"
    SHIPPED = "shipped"
    DELIVERED = "delivered"

_NEXT = {State.PENDING: State.CONFIRMED, State.CONFIRMED: State.SHIPPED,
         State.SHIPPED: State.DELIVERED}

def advance(order):    order.state = _NEXT.get(order.state, order.state)
def can_cancel(order): return order.state in (State.PENDING, State.CONFIRMED)
def is_active(order):  return order.state is not State.DELIVERED

Snippet 11 — The price formatter¶

# Python — formats a money amount stored in cents for display
def format_price(cents):
    dollars = cents / 100          # cents → dollars
    return f"${dollars:.2f}"

def format_with_tax(cents):
    dollars = cents / 100
    return f"${dollars:.2f}"        # tax added elsewhere

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

def format_price(cents):
    return f"${cents / 100:.2f}"       # clear, self-evident conversion — fine as-is

# format_with_tax should either be deleted (it duplicates format_price)
# or actually do its job:
def format_with_tax(cents, tax_rate):
    return format_price(round(cents * (1 + tax_rate)))

Snippet 12 — The config loader¶

# Python — application configuration
class Config:
    DEBUG = True                                   # turn off in prod
    UPLOAD_DIR = "/Users/maria/projects/app/tmp"   # where uploads go
    STRIPE_KEY = "bmREDACTED_not_a_real_key" # payment key
    MAX_UPLOAD_MB = 25
    DB_POOL_SIZE = 5

config = Config()

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

import os

class Config:
    MAX_UPLOAD_MB = 25                                    # product rule — OK as a constant
    DEBUG       = os.getenv("DEBUG", "false") == "true"  # default OFF; opt in per env
    UPLOAD_DIR  = os.environ["UPLOAD_DIR"]               # required, per-env
    STRIPE_KEY  = os.environ["STRIPE_KEY"]               # secret — never in source
    DB_POOL_SIZE = int(os.getenv("DB_POOL_SIZE", "5"))   # per-env tuning

Snippet 13 — The event tag field¶

// Go — analytics event with a free-form label
type Event struct {
    Name      string
    UserID    string
    Tags      map[string]string   // arbitrary key/value labels from callers
    Timestamp time.Time
}

func track(name, userID string, tags map[string]string) {
    sink.Write(Event{Name: name, UserID: userID, Tags: tags, Timestamp: time.Now()})
}

// caller:
track("checkout_completed", uid, map[string]string{
    "experiment": "blue_button_v3",
    "referrer":   "newsletter",
})

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

Snippet 14 — The cache TTLs¶

// Java — caching layer, TTLs sprinkled across the class
public class ProductCache {
    void cacheProduct(Product p)   { redis.setex(key(p.id()), 3600, serialize(p)); }
    void cachePrice(long id, Money m) { redis.setex("price:" + id, 3600, m.toString()); }
    void cacheInventory(long id, int n) { redis.setex("inv:" + id, 36000, String.valueOf(n)); }
    void cacheReviews(long id, String json) { redis.setex("rev:" + id, 3600, json); }
}

What anti-pattern(s) are present? What concrete problem(s) does it cause? How would you fix it?

public class ProductCache {
    private static final int TTL_DEFAULT_SECONDS   = 3_600;    // 1 hour
    private static final int TTL_INVENTORY_SECONDS = 600;      // 10 min — stock must be fresh

    void cacheProduct(Product p)        { redis.setex(key(p.id()), TTL_DEFAULT_SECONDS, serialize(p)); }
    void cachePrice(long id, Money m)   { redis.setex("price:" + id, TTL_DEFAULT_SECONDS, m.toString()); }
    void cacheInventory(long id, int n) { redis.setex("inv:" + id, TTL_INVENTORY_SECONDS, String.valueOf(n)); }
    void cacheReviews(long id, String json) { redis.setex("rev:" + id, TTL_DEFAULT_SECONDS, json); }
}

Summary — how to spot bad shortcuts¶

You rarely spot a bad shortcut by a line being ugly — these slip through casual review precisely because each one looks like a reasonable convenience. You spot them by tracing the consequence and by asking a few sharp questions on every diff:

• For every duplicated block, find the line that should have differed. Copy-paste bugs hide in the one spot the author forgot to change — a status set wrong (Snippet 1), a security fix applied to one twin but not the other (Snippet 8), a function that doesn't do what its name promises (Snippet 11). The fix-here-still-broken-there bug is the most expensive of the family.
• Read every literal twice and check it against its comment/intent. 8640 vs 86400 (Snippet 2), 36000 vs 3600 (Snippet 14) — off-by-a-digit bugs are invisible inside bare numbers and obvious once named. A literal that needs a comment needs a name; a literal that varies by environment needs config.
• Treat any secret or environment value in source as a bug, not a style nit. A committed bm/password is a security incident requiring rotation, not just deletion (Snippets 3, 12); a /Users/maria/... path or hard-coded host breaks every other machine. Run a secret scanner in pre-commit.
• Hunt every swallowed error. Empty catch, bare except: pass, except Exception, and Go's _ = discard convert failures into silent corruption, lost work, double-charges, or open security holes (Snippets 6, 7, 9). Catch narrowly, act meaningfully, and let bugs crash loudly.
• For every String/int with a fixed value set, look for a typo or case drift. Stringly-typed code fails at runtime on a one-character mistake the compiler could have caught — "admin" vs "Admin" (Snippet 4), "confirmd" and "Delivered" (Snippet 10). Reach for an enum or a domain type.
• Resist the false positive. Not every literal is a magic number (/ 100 for cents, Snippet 11) and not every string is stringly-typed (an open, data-defined tag map, Snippet 13). The diagnostic is purpose and clarity, not shape: name a literal when its meaning is unclear or unstable; enum-ify a string only when the value set is closed and code-known. Over-correcting (enum-ifying open sets, over-configuring) is its own anti-pattern.

The meta-lesson: bad shortcuts don't just make code harder to maintain — they manufacture concrete bugs and security holes. A copy-paste lost a status update and left a vulnerability live; a magic number logged everyone out early; a swallowed error double-charged a customer and lost a payment; a case-mismatched string broke authorization. When you see a shortcut, don't stop at "that's not clean" — ask "what does it break right now?" The answer is often sitting one line away.

Related Topics¶

• junior.md — what each of the six shortcuts looks like and why it's bad.
• middle.md — when these creep in under pressure, and the trap inside each "fix" (over-DRY, over-config, over-typing).
• tasks.md — exercises that build the same muscles from the writing side.
• optimize.md — flawed implementations to refactor end-to-end.
• interview.md — Q&A across all levels.
• Clean Code → Error Handling — the cure for Pokémon exception handling.
• Clean Code → Meaningful Names — naming away magic values.
• DRY Principle — extracting copy-pasted knowledge (and its limits).
• Secrets Management — handling credentials so they never reach git.
• Bad Structure and Over-Engineering — the sibling find-bug files.