12 Coding Practices That Reduce Code Readability

In this humorous yet insightful post, the author enumerates twelve coding “techniques” that actually degrade code readability and make maintenance harder.

1. Over‑splitting microservices: one table per service

The developer creates a separate microservice for each database table, leading to a proliferation of services, complex RPC calls, versioning headaches, and difficult deployment coordination.

2. Refactoring without production rollout

New logic is added behind a feature flag but never enabled in production, causing confusion when other developers modify the “new logic” without realizing the flag is off.

3. Writing excessively long methods

Methods longer than 1000 lines are considered a sign of skill, discouraging extraction of smaller, reusable functions and slowing down newcomers.

4. Deeply nested control structures

Methods contain ten or more nested if/try/catch blocks, making the code hard to follow and intimidating for new team members.

5. Random, meaningless variable names

Variables are named arbitrarily (e.g., str1, list2) without reflecting business meaning, leading to forgetfulness and bugs over time.

6. Writing misleading comments

Comments are intentionally altered to convey wrong information, causing developers to waste time deciphering the true intent.

7. Updating code but never updating comments

Code changes diverge from stale comments, resulting in mismatched documentation and confusion.

8. Copy‑pasting code

Repeatedly copying existing code blocks without refactoring leads to duplicated bugs and makes comprehensive changes difficult.

9. Writing detailed technical designs but ignoring them in implementation

Extensive design documents are produced, yet the actual code follows a much simpler, unrelated approach, leaving developers puzzled.

10. Refusing to add logging

The developer trusts the code so much that no logs are added; when an issue occurs in production, debugging becomes extremely hard.

11. Introducing heavyweight frameworks for trivial problems

Complex rule‑engine frameworks are added to solve simple strategy‑selection tasks, unnecessarily increasing system complexity.

12. Reinventing the wheel

Instead of using proven libraries (e.g., Redisson for distributed locks), the team builds custom solutions that are error‑prone.

The author concludes that these practices severely hurt readability and advises developers not to follow them.