The Programmer's Ultimate Revenge: No Comments, Then Quit — And How to Fix Their Mess

The article opens with a vivid scenario: you inherit a departing colleague's order module — 5,000 lines, two-and-a-half comments, variables named a1 through z26, and if nesting that circles the globe. The author (冰河) uses this narrative hook to showcase six classic "revenge code" patterns, each illustrated with real-world Java snippets.

1. Meaningless Naming

A method doSomething(List list, Map map, int num) reveals nothing about domain concepts. Variables a, b, c turn out to be start date, end date, and a threshold — only discoverable after half a day of archaeology against business docs.

2. Comment Desert

Methods span hundreds of lines with comments like // loop, // judge, // return. A payment callback checks sign.length() == 32, status == "2", and type not in ["4","6"] with only // success / // fail as explanation. The author spent an afternoon learning that 32 = MD5 length, 2 = paid status, 4/6 = test callbacks.

3. Arrow-Code Nesting

A permission check nests seven if levels, pushing the innermost return 30 spaces right. The author cites a medical claim that humans get dizzy beyond three indentation levels. Guard clauses would flatten this.

4. God Method

A 1,200-line submitOrder does login check, inventory, pricing, payment, DB save, SMS/email, logging, inventory update, WebSocket, coupons. A shared variable temp mutates five times between line 300 and 800. A 200-line "temporary" block survives for years.

5. Magic Numbers

order.getStatus() == 3

— 3 means what? The digit appears 87 times with different meanings. Negative flags like result == -1 lack constants such as ORDER_STATUS_PAID = 3.

6. Copy-Paste Proliferation

Identical logic duplicated 11 times. A change missed one clone, causing inconsistency bugs.

Why Developers Write This

Deadline pressure : "No time for naming/comments" — but orderList vs list1 costs two seconds; the "later" never comes.

"I understand it" : Pinyin variables ( yonghuming, dingdanhao) or personal abbreviation systems ( usrOrdPrdRlt) that only the author decodes.

Misguided "good code" : Equating clever one-liners (bitwise addition, stream chains) with quality, ignoring debuggability and readability.

Four-Step Refactoring Playbook

Step 1: Understand Before Touching

Run the code with varied inputs (null, empty, boundary) to infer behavior.

Draw flowcharts / mind-maps of the logic.

Write unit tests covering key paths before any change.

Step 2: Extract Methods (Verb + Noun)

Split god methods into validatePreConditions, calculateAmount, saveOrderToDB, sendNotifications.

Keep parameters ≤ 5; bundle excess into context objects ( UserContext).

Step 3: Naming & Comment Standards

Variables: noun/adjective+noun ( orderList, maxLength).

Methods: verb+noun ( validateOrder, calculatePrice).

Classes: PascalCase nouns ( OrderService).

Constants: UPPER_SNAKE_CASE ( MAX_LENGTH_THRESHOLD).

Comments: Javadoc for public methods; explain why for complex rules (e.g., discount change history); actionable TODOs with owner/timeline; delete noise like // i++.

Step 4: Structural Optimization

Guard clauses replace nested if — return early for null/invalid.

Switch (or Java 14+ switch expressions) replaces if-else chains on enums/status codes.

Collection.contains replaces multiple || checks; define allowed values as constants.

Extract duplicates into reusable methods ( validateToken, formatDate).

Design patterns : Strategy + Factory for payment types — new processors added without touching existing code (Open/Closed Principle).

Team-Level Prevention

Real code reviews : Reject a/b/c names, demand comments for complex logic, flag >3 nesting levels.

Enforced coding standards via Checkstyle/ESLint — no single-letter vars (except loop indices), mandatory Javadoc for public APIs, magic numbers as constants, method length limits.

Scheduled tech-debt sprints (e.g., 20% per iteration) and the Boy Scout Rule: leave code cleaner than you found it.

Knowledge sharing : Regular "worst code I've seen" sessions; senior-junior pair walkthroughs.

Structured offboarding : Code walkthroughs, "code self-description" docs, pre-departure refactoring of obvious smells.

The piece closes with a reflective twist: the ultimate revenge isn't the messy code — it's making the maintainer hate you forever. The antidote: write comments for your future self, because three months from now you will be the one staring at the screen with goji tea on your keyboard.