12 Coding Anti‑Patterns That Destroy Readability (And How to Avoid Them)

1. Over‑splitting microservices: one table per service

Er Gou loves microservices and creates a separate service for every database table, resulting in a complex architecture with many RPC calls, versioning headaches, and performance issues. New developers struggle to understand and deploy the numerous services.

2. Refactoring without production rollout

Er Gou adds new logic behind a feature flag and marks it with a comment, but only enables it in the test environment. When the flag is not turned on in production, the new code fails, causing delays and frustration for the new teammate.

3. Writing excessively long methods

He believes that longer methods are more coherent and impressive, so he writes methods exceeding 1,000 lines and never extracts smaller functions, making the code hard to follow.

4. Deeply nested control structures

Er Gou nests if/try/catch blocks more than ten levels deep, claiming high code quality, while newcomers find the code incomprehensible.

5. Random, meaningless variable names

He uses arbitrary names like str1, list2 without reflecting business logic, which later become confusing as the original meaning is forgotten.

6. Writing misleading comments

Er Gou intentionally adds incorrect or swapped comments, leading others to misunderstand the code’s intent.

7. Never updating comments after code changes

He modifies code extensively but leaves the original comments untouched, causing a mismatch between code and documentation.

8. Blindly copying code

When in a hurry, Er Gou copies existing code blocks without refactoring, resulting in duplicated logic that is hard to maintain and introduces bugs when only some copies are updated.

9. Ignoring the technical design document

Although he writes detailed design documents, he implements a much simpler solution in code, leaving a gap between the design and the actual implementation.

10. Refusing to add logging

Confident in his code, Er Gou never adds logs, which later hampers troubleshooting during production incidents.

11. Over‑engineering with heavyweight frameworks

He introduces complex rule‑engine frameworks to solve simple strategy‑selection problems, making the system harder to understand.

12. Reinventing the wheel

Instead of using proven libraries (e.g., Redisson for distributed locks), he builds his own solution with SETNX, leading to additional bugs.

Conclusion

The twelve practices above illustrate how certain habits dramatically reduce code readability and maintainability; developers should avoid them.