How to Write Unmaintainable Code: A Satirical Guide

1. Naming

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

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

Creative misspellings : e.g., SetPintleOpening , SetPintalClosing

Abstract names : e.g., ProcessData , DoIt , GetData

Acronyms : e.g., WTF , RTFSC , even pinyin acronyms like BT , TMD

Random capitalisation : e.g., gEtnuMbER

Reused names : using the same identifier in nested blocks

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

Underscores : e.g., _ , __ , ___

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 : use characters that look alike

2. Deceptive Tricks

Interleaving comments and code : for(j=0; j

Code‑UI mismatch : UI shows “postal code” while code uses zipcode

Hide globals : pass a global variable as a function argument to disguise its scope

Similar variable names : e.g., swimmer vs swimner , ilI1| , parselnt vs parseInt

Function overloading with unrelated behaviour

Operator overloading : overload ! to return an integer, then chain !! or !!!

3. Documentation and Comments

Lie in comments : never update comments after code changes

Write nonsense in comments : e.g., /* add 1 to i */

Document the “what” but not the “why”

Avoid commenting secrets : never reveal critical implementation details

Excessive detail : write hundreds of pages of minutiae, many nested sections, and inconsistent units

Gotchas : never comment about known pitfalls

Vent frustrations in comments

4. Design

Java casts : overuse explicit casts from collections

Exploit Java redundancy : duplicate similar code with tiny variations

Never validate input or return values

Don’t encapsulate : expose all internal details to callers

Copy‑paste cloning

Huge listeners : a single listener with massive if…else chains for all buttons

Higher‑dimensional arrays : use 3‑D, 4‑D, etc.

Mix getters/setters with public fields

Deep wrapper layers : wrap APIs 6‑8 times, with >4 layers of nesting

Make everything public

Swap parameter order repeatedly : e.g., drawRectangle(height, width) then later drawRectangle(width, height)

Rename methods arbitrarily : e.g., setAlignment becomes setLeftAlignment , setRightAlignment , etc.

Keep dead code : never delete unused variables or methods

Seal all subclasses : mark them final to prevent extension

Avoid layout managers : hard‑code absolute coordinates or use GridBagLayout with fixed grid positions

Environment‑variable initialization : initialise members from env vars instead of constructors

Global variables everywhere : initialise them in unrelated functions and pass them implicitly

Configuration file mismatch : make config keys differ from code identifiers

Bloated classes : pack many unrelated methods into a single class

Deep inheritance hierarchies : ten levels of inheritance for ten fields

XML overuse : replace short code with massive XML files

Split simple conditions : rewrite a==100 as a>99 && a<101

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

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

Excessive nesting : >10 parentheses in one line or >20 nested blocks

Long lines : make each line as long as possible

Avoid early returns : use deep if‑else chains instead of break

Omit braces : remove {} from if/else blocks and mis‑indent

Trivial wrappers : wrap a bool in a class that does nothing

Swap loops : replace for with while , invert bounds, change < to <= , adjust step direction

5. Testing

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

Never do performance testing : tell users to upgrade hardware instead

Don’t write test cases : avoid coverage or automation tests

View testing as cowardice : claim a brave programmer needs no tests

6. Others

The boss knows everything : obey blindly to learn more ways to break maintainability

Subvert the Help Desk : hide bugs from support, deflect users to re‑install or blame accounts

Keep quiet about big bugs : never disclose them, even to friends or colleagues

Obfuscate with buzzwords : label terrible code with GoF patterns or “agile” to impress the industry

Write Everywhere, Read Nowhere – the article’s motto.