How to Write Code Nobody Can Maintain – A Satirical Guide

01 Variable Naming

Easy‑to‑type names: Use short names like Fred or asdf.

Single‑letter names: a, b, c, x, y, z (or a1, a2 if you run out).

Creative misspellings: SetPintleOpening, SetPintalClosing to make searching hard.

Abstract names: ProcessData, DoIt, GetData – say nothing.

Acronyms: WTF, RTFSC, even pinyin acronyms like BT, TMD.

Random capitalisation: gEtnuMbER.

Reuse names in nested scopes: Same variable name inside inner blocks.

Accent characters: int ínt (second character is not int).

Underscores: _, __, ___.

Mix languages: Combine English, German, or Chinese pinyin.

Symbolic names: slash, asterix, comma.

Irrelevant words: god, superman, iloveu.

Confuse l and 1: Use lowercase L and digit one interchangeably.

02 Deceptive Obfuscation

Interleave comments and code to hide 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 calls a field postal code but code uses zipcode.

Hide global variables by passing them as function parameters.

Use similar variable names (e.g., swimmer vs swimner, ilI1| vs oO08, parselnt vs parseInt).

Overload functions with unrelated implementations.

Operator overloading to create bizarre behavior (e.g., overload ! to return an integer, then apply !!).

03 Documentation and Comments

Lie in comments by not updating them after code changes.

Write useless comment text (e.g., /* add 1 to i */).

Document *what* a piece of code does, not *why*.

Never comment secrets; hide critical business logic.

Over‑detail designs: write hundreds of pages, thousands of numbered sections, and dozens of measurement units.

Never document pitfalls ("Gotchas").

Avoid venting frustrations in comments.

04 Design Abuse

Java casts: Rely heavily on type casts from collections.

Exploit Java redundancy: Duplicate classes with minor name changes.

Never validate input or return values.

Don’t encapsulate: Expose all internal details to callers.

Copy‑paste cloning: Duplicate code instead of understanding it.

Massive listeners: One listener handling all button events with huge if…else chains.

High‑dimensional arrays: Use 3‑D or even 4‑D arrays unnecessarily.

Mix access styles: Combine getters/setters with direct public field access.

Deep wrapping: Wrap APIs 6‑8 times, creating 4+ layers of indirection.

Make everything public: No secrets, high coupling.

Parameter order chaos: Swap function argument order across releases.

Rename methods arbitrarily: setAlignment becomes setLeftAlignment, etc.

Keep dead code: Never delete unused variables, methods, or classes.

Seal subclasses: Mark all child classes final to prevent extension.

Avoid layout managers: Hard‑code absolute coordinates or misuse GridBagLayout.

Environment‑driven initialization: Initialise members from env vars instead of constructors.

Global variables everywhere: Initialise them in unrelated functions and pass fewer parameters.

Mislead with config files: Use different names in config than in code.

Bloat classes: Provide every possible method in a single class.

Excessive subclassing: Create deep inheritance hierarchies with one property per level.

XML overload: Inflate tiny code blocks into massive XML files.

Split simple conditions: Rewrite a == 100 as a > 99 && a < 101.

Abuse semicolons: if (a); else; { int d; d = c; } Indirect casting: new Double(d).toString() instead of Double.toString(d).

Deep nesting: More than 10 levels of parentheses or 20 levels of braces.

Long lines: Write extremely long statements to force horizontal scrolling.

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(int i=0;i<n;i++) with a convoluted while and altered conditions.

05 Testing

Never test error handling or system‑call return values.

Never perform performance testing; blame the hardware instead.

Don’t write test cases or measure code coverage.

Consider testing cowardly; a "real" programmer doesn’t need it.

06 Miscellaneous

Obey a clueless boss to learn more ways to break maintainability.

Hide bugs from the support team; give users vague answers.

Keep major bugs secret to profit later.

Label bad code with buzzwords like GoF patterns or Agile to impress others.