How to Write Unmaintainable Code: A Satirical Guide by a Top Architect

The author, a self‑proclaimed top architect, claims to teach how to write code that colleagues cannot maintain.

1. Variable Naming

Use easy‑to‑type names like "Fred" or "asdf".

Single‑letter names such as a, b, c, or a1, a2, a3.

Deliberate misspellings like "SetPintleOpening".

Abstract names like "ProcessData" or "DoIt".

Acronyms and slang (WTF, RTFSC, BT, TMD, etc.).

Random capitalisation, e.g., "gEtnuMbER".

Reuse the same name in nested blocks.

Use accented characters, e.g., "int ínt".

Underscores: _, __, ___.

Mix languages (English, German, Chinese pinyin).

Use symbols as names: "slash", "asterix", "comma".

Unrelated words: "god", "superman", "iloveu".

Confuse the letter l with the digit 1.

2. Deception and Fraud

Interleave comments and code.

Make code and UI inconsistent (e.g., variable named "postal code" in UI but "zipcode" in code).

Hide global variables by passing them as function parameters.

Use similar variable names (swimmer vs swimner, ilI1|, parseInt vs parselnt, D0Calc vs DOCalc, xy_Z vs xy__z, etc.).

Overload functions with unrelated behaviour.

Operator overloading to create confusing semantics.

Example of a confusing code block: for(j=0; j

3. Documentation and Comments

Lie in comments by not updating them.

Add useless comments (e.g., "/* add 1 to i */").

Document only the "what", not the "why".

Avoid documenting secrets.

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

Never comment pitfalls.

Vent frustrations in comments.

4. Program Design

Abuse Java casts everywhere.

Exploit Java redundancy (e.g., duplicate class names, similar variable spellings).

Never validate inputs or return values.

Do not encapsulate; expose all internal details.

Rely on copy‑paste instead of understanding code.

Create huge listeners with many if‑else branches.

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

Mix getters/setters with public fields.

Wrap APIs multiple times (6‑8 layers, 4+ levels deep).

Make everything public.

Swap parameter orders inconsistently.

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

Keep unused code, methods, and variables.

Seal all subclasses to prevent extension.

Avoid layout managers; hard‑code coordinates.

Initialize members from environment variables.

Scatter global variable initialisation across unrelated functions.

Misalign config file names with code names.

Inflate classes with many unrelated methods.

Use XML to bloat simple code.

Decompose simple conditions into verbose forms.

Misuse semicolons to create dead code.

Indirect type conversion (new Double(d).toString()).

Deep nesting of parentheses and blocks.

Long code lines to force scrolling.

Avoid early returns; use many nested if‑else.

Omit braces and use irregular indentation.

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

Swap loops (use while instead of for, change bounds, etc.).

5. Testing

Never test error handling.

Never perform performance testing.

Do not write test cases or measure coverage.

Consider testing cowardly; claim real programmers do not need tests.

6. Others

Obey the boss blindly, even if the boss is incompetent.

Hide bugs from the help desk and users.

Keep silent about major bugs to later profit from them.

Over‑sell code with buzzwords, design‑pattern labels, and agile jargon.

Conclusion: The slogan is “Write Everywhere, Read Nowhere”.