How to Write Code Nobody Can Maintain – A Satirical Guide

1. Program Naming

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

Single‑letter names : e.g., a, b, c (or a1, a2 if needed).

Creative misspellings : e.g., SetPintleOpening, SetPintalClosing to thwart search.

Abstract names : e.g., ProcessData, DoIt, GetData —so vague they say nothing.

Acronyms and slang : e.g., WTF, RTFSC, or Chinese‑pinyin abbreviations like BT, TMD.

Random capitalisation : e.g., gEtnuMbER.

Reusing names : use the same identifier in nested blocks for “magic”.

Accent‑marked letters : e.g., int ínt where the second character is not int.

Underscores : _, __, ___.

Mixing languages : combine English, German, or Chinese pinyin in identifiers.

Symbolic names : e.g., slash, asterix, comma.

Irrelevant words : e.g., god, superman, iloveu.

Confusing l and 1 : make them indistinguishable.

2. Deception & Fraud

Interleave comments with code to hide intent.

Inconsistent UI vs. code : UI shows “postal code” while code uses zipcode.

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

Similar variable names : swimmer vs. swimner, ilI1| vs. oO08, parselnt vs. parseInt, etc.

Function overloading with unrelated behaviour : same name, different logic.

Operator overloading abuse : overload ! to return an integer, then chain !! for bizarre effects.

3. Documentation & Comments

Lie in comments by never updating them after code changes.

Write useless comment lines like /* add 1 to i */.

Document only the “what”, never the “why”.

Never comment on secrets; for example, hide the fact that adding a new flight requires modifying dozens of places.

Over‑detail designs: produce hundreds of pages, deep paragraph numbering, and exhaustive unit specifications (seconds vs. milliseconds, pixels vs. inches, MB vs. KB).

Include “Gotchas” without warning readers.

Vent frustrations in comments and documentation.

4. Program Design

Java casts : rely heavily on runtime casts from collections, making type changes hard to track.

Exploit Java redundancy : duplicate similar statements with tiny variations.

Never validate input or return values : trust the system blindly.

Avoid encapsulation : expose all internal details to callers.

Clone & copy : use copy‑and‑paste liberally, ignoring understanding of code.

Massive listeners : funnel all button actions through a single gigantic listener with many if…else branches.

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

Mix getters/setters with direct field access to confuse maintainers.

Over‑wrap APIs : layer 6‑8 wrappers, 4+ levels deep, duplicating functionality.

Make everything public so no access control is possible.

Inflate classes : pack every conceivable method into a single bloated class.

Use subclass explosion : create deep inheritance hierarchies for each field.

XML over‑engineering : replace a 10‑line program with a 100‑line XML file.

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

Abuse semicolons : e.g., if (a); else; { int d; d = c; }.

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

Deep nesting : nest more than ten parentheses or twenty braces in a single function.

Long lines : write extremely long statements to force scrolling.

Avoid early returns and breaks : force multi‑level if‑else chains.

Omit braces even in complex if‑else blocks, and mis‑indent deliberately.

Trivial encapsulation : wrap a boolean in a class that does nothing else.

Swap loop constructs : replace for(int i=0;i<n;i++) with a convoluted while version.

5. Testing

Never write tests, especially for error handling or system‑call return values.

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

Avoid test cases, code‑coverage metrics, and automation.

Claim testing is cowardly; a “real” programmer trusts their code implicitly.

6. Other Tips

Obey an omniscient boss, no matter how unreasonable.

Silence help‑desk inquiries; redirect users to re‑install or blame their accounts.

Keep major bugs secret to profit from them later.

Dress bad code with buzzwords like GoF patterns or Agile, even if the implementation is terrible.

Overall slogan: Write Everywhere, Read Nowhere .