How to Write Code Nobody Can Maintain – A Satirical Guide

1. Variable Naming

Easy‑to‑type names : e.g., Fred, asdf.

Single‑letter names : a, b, c, x, y, z (or a1, a2, …).

Creative misspellings : SetPintleOpening, SetPintalClosing.

Abstract names : ProcessData, DoIt, GetData.

Acronyms : WTF, RTFSC, BT, TMD, TJJTDS.

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 : use l and 1 interchangeably.

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 shows “postal code” while code uses “zipcode”.

Hide globals : pass global variables as function parameters.

Similar variable names : swimmer vs swimner, ilI1|, oO08, parseInt vs parselnt, D0Calc vs DOCalc, xy_Z, xy__z, _xy_z, etc.

Function overloading with unrelated behavior .

Operator overloading : overload ! to return an integer, then apply !!.

3. Documentation and Comments

Lie in comments by not updating them.

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

Document *what* instead of *why*.

Avoid mentioning secrets in comments.

Write overly detailed documentation with hundreds of pages and deep numbering.

Never comment on pitfalls.

Vent frustrations in comments.

4. Design Practices

Abuse Java casts and redundant type conversions.

Never validate input or return values .

Don’t encapsulate : expose all internal details.

Copy‑paste cloning instead of understanding code.

Massive listeners with huge if‑else chains.

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

Mix getters/setters with direct field access .

Wrap APIs repeatedly (6‑8 layers deep).

Make everything public to increase coupling.

Swap parameter order repeatedly to confuse maintainers.

Rename methods arbitrarily (setAlignment → setLeftAlignment, etc.).

Keep dead code and unused variables.

Seal classes with final to prevent inheritance.

Avoid layout managers and hard‑code absolute coordinates.

Rely on environment variables for initialization .

Misalign configuration names with code names .

Inflate classes with many unrelated methods .

Deep inheritance hierarchies for each field.

Convert simple code to XML to bloat size.

Break simple conditions into complex expressions .

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

Indirect casting : new Double(d).toString() instead of Double.toString(d).

Excessive nesting (10+ parentheses, 20+ nested blocks).

Long lines of code to force scrolling.

Avoid early returns and breaks , forcing deep if‑else chains.

Omit braces and use irregular indentation.

Trivial encapsulation (e.g., a bool class that does nothing).

Swap loop constructs (use while instead of for, invert bounds, change < to <=, decrement i).

5. Testing Strategies

Never write tests, especially for error handling.

Avoid performance testing; blame the user’s hardware.

Don’t create test cases or measure coverage.

Consider testing a cowardly act; real programmers don’t need it.

6. Miscellaneous Advice

Obey your boss’s every whim, no matter how absurd.

Hide bugs from the help desk; give generic “reset” answers.

Keep major bugs secret to profit later.

Label bad code with GoF patterns or “agile” buzzwords.

Write Everywhere, Read Nowhere