How to Write Unmaintainable Code: A Satirical Guide to Bad Programming Practices

The author, claiming to be a "top architect," humorously claims to teach readers how to write code that colleagues cannot maintain.

01. Variable Naming

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

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

Creative misspellings : SetPintleOpening, SetPintalClosing to make searching hard.

Abstract names : ProcessData, DoIt, GetData – so vague they say nothing.

Acronyms : WTF, RTFSC, or Chinese pinyin acronyms like BT, TMD, TJJTDS.

Random capitalisation : gEtnuMbER…

Reused names : using the same variable name in nested blocks for “effect”.

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

Underscores : _, __, ___ etc.

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

Symbolic names : slash, asterix, comma…

Irrelevant words : god, superman, iloveu…

Confuse l and 1 : they look alike.

02. Deceptive Practices

Interleave comments and code to hide intent.

Code/display mismatch : UI calls it "postal code" but code uses "zipcode".

Hide global variables by passing them as function parameters.

Similar variable names : swimmer vs swimner, ilI1|, oO08, parseInt vs parselnt, D0Calc vs DOCalc, xy_Z, xy__z, _xy_z, _xyz, XY_Z, xY_z, Xy_z.

Overload functions with unrelated implementations.

Operator overloading (e.g., overload ! to return an int, then chain !!!).

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

03. Documentation and Comments

Lie in comments by not updating them after code changes.

Write useless comments : /* add 1 to i */.

Comment what, not why.

Never expose secrets in comments (e.g., require changing >25 places for a new flight).

Detail everything – write massive design documents with hundreds of pages and deep numbering.

Gotchas : never comment traps.

Vent frustrations in comments .

04. Program Design

Java casts : excessive type casting from collections.

Exploit Java redundancy : e.g., Bubblegum b = new Bubblegom(); swimmer = swimner + 1.

Never validate input or return values .

Don’t encapsulate : callers must know all details.

Copy‑paste code without understanding.

Huge listeners with massive if‑else chains.

Use multi‑dimensional arrays (even four‑dimensional).

Mix get/set methods with direct public field access .

Deep wrapper layers (6‑8 times, >4 levels deep).

Make everything public to increase coupling.

Swap argument order repeatedly (e.g., drawRectangle(height, width) then back).

Rename methods to reflect alignment : setAlignment → setLeftAlignment, setRightAlignment, setCenterAlignment.

Keep unused variables, methods, and code .

Make all subclasses final so they cannot be extended.

Avoid layout managers ; hard‑code GridBagLayout coordinates.

Initialise members from environment variables instead of constructors.

Use global variables scattered across unrelated functions.

Mis‑match configuration file names with code names.

Inflate classes with many obscure methods.

Use inheritance hierarchies for every field (10 levels, each in separate files).

Introduce XML to bloat code.

Decompose conditions : a==100 → a>99 && a<101.

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

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

Deep nesting : >10 parentheses layers or >20 nested blocks.

Long code lines : make lines as long as possible.

Avoid early returns and use many nested if‑else levels.

Never use braces in if‑else statements.

Trivial wrappers : a bool class that does nothing but hold a boolean.

05. Testing

Never test error handling or system call return values.

Never perform performance testing ; blame the user’s machine instead.

Don’t write test cases or measure code coverage.

Claim testing is cowardly and unnecessary for a confident programmer.

06. Others

Obey the boss no matter how incompetent to learn more unmaintainable tricks.

Subvert the help desk by ignoring user reports.

Keep silent about major bugs to profit later.

Spin hype by labeling bad code with GoF patterns and agile buzzwords.

Final disclaimer: This article is a reverse example; please do not imitate these practices.