How to Write Code Nobody Can Maintain: A Satirical Guide to Anti‑Patterns

01 Program Naming

Easy‑to‑type variable names : e.g., Fred, asdf Single‑letter names : e.g., a, b, x, y, z (or a1, a2 …)

Creative misspellings : e.g., SetPintleOpening, SetPintalClosing to hinder search

Abstract names : e.g., ProcessData, DoIt, GetData —meaningless

Acronyms and slang : e.g., WTF, RTFSC, Chinese pinyin abbreviations like BT, TMD Random capitalisation : e.g., gEtnuMbER Reuse names in nested scopes to create confusion

Accent characters : e.g., int ínt where the second character is not int Underscores : e.g., _, __, ___ Mix languages : combine English, German, or Chinese pinyin

Symbolic names : e.g., slash, asterix, comma Irrelevant words : e.g., god, superman, iloveu Confuse l and 1 : make them indistinguishable

02 Disguise Deception

Interleave comments and code to obscure intent

for (j = 0; j < array_len; j += 8) {
    total += array[j+0];
    total += array[j+1];
    total += array[j+2]; /* Main body of
    total += array[j+3]; * loop is unrolled */
    total += array[j+4]; * for greater speed.
    total += array[j+5]; */
    total += array[j+6];
    total += array[j+7];
}

Code/display mismatch : UI says "postal code" while code uses zipcode Hide globals : pass global variables as function parameters to disguise them

Similar variable names : e.g., swimmer vs swimner, ilI1| vs oO08, parseInt vs parselnt Function overloading with unrelated behaviour

Operator overloading : overload ! to return an integer, creating bizarre chains like

!!!

03 Documentation and Comments

Lie in comments : never update comments when code changes

Write useless comments : e.g., /* add 1 to i */ Comment only the "what", not the "why"

Avoid commenting secrets : never disclose critical design constraints

Over‑detail designs : write hundreds of pages of minutiae, excessive section numbering, and unit specifications

Gotchas : never comment on pitfalls

Vent frustration in comments

04 Program Design

Java casts : overuse type casting from collections

Exploit Java redundancy : duplicate similar code with tiny variations

Never validate input or return values

Don’t encapsulate : expose all internal details to callers

Copy‑paste cloning : avoid understanding existing code

Huge listener : a single listener with massive if…else chains

Use multi‑dimensional arrays (even four‑dimensional)

Mix access methods : combine getters/setters with direct public field access

Deep packaging : wrap APIs 6‑8 times, with >4 layers of nesting

No secrets : make every member public Swap parameter order across releases to confuse maintainers

Rename methods arbitrarily : e.g., setAlignment becomes setLeftAlignment, etc.

Keep dead code forever

Make all subclasses final to block inheritance

Avoid layout managers : hard‑code absolute coordinates, or misuse GridBagLayout Environment variables for initialization instead of constructors

Global variables everywhere : initialise them in unrelated functions and use them to reduce parameter count

Mismatched config names : configuration keys differ from code identifiers

Inflate classes : overload a class with many obscure methods

Excessive subclassing : deep inheritance hierarchies with one feature per level

XML bloat : replace short code with verbose XML

Decompose conditions : rewrite a==100 as a>99 && a<101 Abuse semicolons : e.g., if (a); else; { int d; d = c; } Indirect casting : new Double(d).toString() instead of Double.toString(d) Deep nesting : >10 parentheses in a line, >20 nested blocks

Long lines : make each line as long as possible

Avoid early returns : use many nested if‑else instead of break Omit braces : write if / else without {} and mis‑indent

Trivial encapsulation : wrap a bool in a class that does nothing

Loop tricks : replace for with while, swap bounds, change < to <=, decrement iterator

05 Testing

Never test : skip error‑handling tests and system‑call return checks

Never do performance testing : blame the user’s hardware instead

Don’t write test cases : avoid coverage and automation

View testing as cowardice : claim brave programmers need no tests

06 Other

Obey the boss blindly , even if they are incompetent

Hide bugs from the help desk : ignore user reports or give generic answers

Keep silent about major bugs to profit later

Spin nonsense : label terrible code with design‑pattern or agile buzzwords to impress stakeholders

Write Everywhere, Read Nowhere