12 Coding Anti‑Patterns That Reduce Readability and Increase Maintenance Difficulty

After six or seven years of handling countless messy projects, the author lists twelve coding “techniques” that dramatically reduce code readability and increase maintenance difficulty.

1. One table per microservice

The programmer enthusiastically applies microservice principles to the extreme, creating a separate service for every database table, which results in a complex architecture, massive RPC overhead, version‑conflict issues, and poor performance.

2. Refactoring without releasing

Although new logic is added and annotated, it is only enabled in the test environment; the switch remains off in production, causing new teammates to modify code that never runs and leading to failed deployments.

3. Writing methods longer than 1,000 lines

The belief that longer methods are more coherent leads to monolithic functions that are hard to understand, refactor, or test, slowing down newcomers and increasing bug risk.

4. Deeply nested control structures

Excessive nesting of if / try / else blocks (often more than ten levels) makes the code virtually unreadable, forcing teammates to seek help just to comprehend the flow.

5. Random, meaningless variable names

Variables are named arbitrarily (e.g., str1 , list2 ) without reflecting business meaning, which quickly becomes confusing as the original author forgets their purpose.

6. Incorrect or misleading comments

Comments are deliberately altered to convey wrong information, swapped, or left unchanged after code modifications, causing future developers to trust inaccurate documentation.

7. Copy‑paste coding habit

Code snippets are duplicated across the codebase without abstraction, leading to duplicated bugs and making it hard for newcomers to track all required changes.

8. Writing detailed technical proposals but ignoring them in implementation

Extensive design documents (e.g., a complex Redis‑based flash‑sale system) are written, yet the actual implementation falls back to a simplistic solution, creating a gap between documentation and reality.

9. Refusing to add logging

The developer’s confidence leads to a complete lack of logging; when production issues arise, debugging becomes extremely difficult, sparking blame‑shifting discussions.

10. Introducing heavyweight frameworks for trivial problems

Advanced rule‑engine frameworks (Drools, SPEL, etc.) are added to solve simple strategy‑selection logic, inflating the system’s complexity and steepening the learning curve for new team members.

11. Reinventing the wheel

Instead of using proven libraries (e.g., Redisson for distributed locks), a custom solution based on SETNX is built, which later causes reliability issues.

12. Summary

The twelve practices listed above are typical ways to degrade code readability; developers should avoid them to maintain a healthy codebase.