How to Write Code Nobody Can Maintain – A Satirical Guide

Naming Practices that Obfuscate Code

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

Deliberate misspellings : e.g., SetPintleOpening, SetPintalClosing Overly abstract verbs : ProcessData, DoIt, GetData Acronyms and slang : WTF, RTFSC, Chinese pinyin abbreviations such as BT, TMD Random capitalisation : e.g., gEtnuMbER Reusing names in nested scopes

Accent characters : e.g., int ínt (second token is not the keyword int)

Underscore‑only identifiers : _, __, ___ Mixing languages : combine English, German, or Chinese pinyin in the same code base

Symbolic names : slash, asterix, comma Irrelevant words : god, superman, iloveu Visually similar characters : confuse l with

1

Deceptive Tricks

Interleaving comments and code to hide logic:

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 and code identifiers : UI shows “postal code” while the code uses zipcode Hiding globals : pass a global variable as a function parameter to disguise its global nature

Similar variable names : swimmer vs swimner, ilI1| vs oO08, parseInt vs parselnt Function overloading with unrelated semantics

Operator overloading abuse : overload ! to return an integer, then chain !! or !!! for confusing results

Documentation and Comments

Stale or false comments : never update comments after code changes

Nonsense comments : e.g., /* add 1 to i */ Document only the “what”, never the “why”

Deliberately omit pitfalls from documentation

Vent frustrations in comments, adding noise rather than insight

Design Practices that Increase Unmaintainability

Excessive runtime casts (e.g., casting Object from collections to concrete types everywhere)

Redundant Java statements with subtle differences to create confusion

No input or return‑value validation

Never encapsulate : expose all internal fields directly to callers

Copy‑paste cloning without understanding existing code

Monolithic listeners : a single listener handling all UI events with long if…else chains

Unnecessary high‑dimensional arrays : use 3‑D or 4‑D arrays where a simple 1‑D structure would suffice

Mix direct field access with getters/setters to break consistency

Deep wrapper chains : wrap the same API 6‑8 times, creating 4+ layers of similar functionality

Make everything public , eliminating access control and increasing coupling

Arbitrary parameter reordering across releases, breaking callers' expectations

Inconsistent method renaming : e.g., setAlignment → setLeftAlignment, setRightAlignment Retain dead code : keep unused variables, methods, and classes in the code base

Seal classes with final to prevent inheritance

Avoid layout managers : hard‑code absolute coordinates or GridBagLayout indices

Misuse environment variables for object initialization instead of constructors

Global variables initialized in unrelated functions and passed implicitly

Configuration‑code name mismatch : use different names in config files and source code

Bloat classes with many unrelated methods

Excessive inheritance depth with one member per level spread across many files

XML overuse : replace short code with verbose XML structures

Split simple conditions : rewrite a == 100 as a > 99 && a < 101 Abuse of stray semicolons : e.g., if (a); else; { int d; d = c; } Indirect casting : new Double(d).toString() instead of Double.toString(d) Deep nesting : >10 levels of parentheses or >20 levels of braces

Excessively long lines to force horizontal scrolling

Avoid early returns : use many nested if‑else blocks instead of break Omit braces on if/else statements and mis‑indent deliberately

Trivial encapsulation : wrap a primitive boolean in an empty class

Swap loop constructs : replace for with while, invert bounds, or change comparison operators

Testing Attitudes

Never write tests : skip error‑handling tests and system‑call return checks

Never perform performance testing : blame hardware instead of improving the algorithm

Avoid test case creation and code‑coverage measurement

Dismiss testing as cowardice , claiming that a brave programmer needs no tests

Other Counterproductive Advice

Blindly obey unreasonable directives from management to learn “how to write unmaintainable code”

Hide bugs from support teams and blame users for failures

Keep serious bugs secret , even from colleagues and family

Mask poor code with buzzwords such as “GoF pattern” or “Agile” to give a false impression of quality