How to Write Code Nobody Can Maintain – A Satirical Guide

1. Naming

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

Creative misspellings : SetPintleOpening, SetPintalClosing Abstract names : ProcessData, DoIt, GetData Acronyms : WTF, RTFSC, even pinyin acronyms like BT Random capitalisation : gEtnuMbER Reuse names : same variable name in nested blocks

Accent characters : int ínt Underscores : _, __, ___ Mix languages : English, German, Chinese pinyin

Symbolic names : slash, asterix, comma Irrelevant words : god, superman, iloveu Confuse l and 1

2. Deceptive Tricks

Interleave comments and code

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];
}

Mismatched UI labels : UI says “postal code” while code uses “zipcode”

Hide globals : pass global variables as function parameters to disguise them

Similar variable names : swimmer vs swimner, ilI1, parseInt vs parselnt Overload functions with unrelated implementations

Operator overloading to produce confusing behaviour (e.g., overload ! to return an integer)

3. Documentation & Comments

Lie in comments by not updating them after code changes

Write nonsense comments like /* add 1 to i */ Document the what, not the why

Never document secrets (e.g., hidden dependencies)

Excessive detail – hundreds of pages, deep numbering, redundant units

Gotchas – never comment pitfalls

Vent frustrations in comments

4. Design

Java casts everywhere, even when unnecessary

Exploit Java redundancy (e.g., Bubblegum b = new Bubblegom();)

Never validate input or return values

Avoid encapsulation – expose all details to callers

Copy‑paste cloning instead of understanding code

Massive listeners with long if…else chains

Use high‑dimensional arrays (4‑D, etc.)

Mix direct field access with getters/setters

Deeply wrap APIs (6‑8 layers)

Make everything public to increase coupling

Swap parameter order repeatedly across releases

Rename methods arbitrarily (e.g., setAlignment → setLeftAlignment)

Keep dead code – unused variables, methods, classes

Seal classes with final to prevent inheritance

Avoid layout managers and hard‑code absolute coordinates

Misuse environment variables for class initialization

Global variables everywhere – initialise in unrelated functions

Mismatched config names vs code identifiers

Bloated classes with many obscure methods

Excessive subclassing – ten levels of inheritance for ten fields

XML overuse to inflate code size

Decompose conditions ( a==100 → a>99 && a<101)

Abuse semicolons ( if (a); else; { int d; d=c; })

Indirect casting ( new Double(d).toString())

Deep nesting – >10 parentheses or >20 block levels

Long lines to force scrolling

Avoid early returns and break Omit braces and use chaotic indentation

Trivial encapsulation (e.g., a class that only wraps a boolean)

Swap loops ( for vs while, change bounds, etc.)

5. Testing

Never test error handling or system call returns

Never do performance testing – blame the user’s hardware

Don’t write test cases or coverage checks

Consider testing cowardly – a “real” programmer doesn’t need it

6. Other Tips

Obey the boss blindly to learn more ways to break maintainability

Hide bugs from the help desk and give users vague excuses

Keep big bugs secret to profit later

Dress bad code with GoF patterns and Agile buzzwords to confuse the industry

Write Everywhere, Read Nowhere