Eliminating YAGNI Smell, When to Use Comments, and Effective Code Review Practices

Most software development cost is maintenance, and the YAGNI (You Aren't Gonna Need It) principle helps keep code lean by implementing features only when they are truly needed.

Eliminate YAGNI Smell

YAGNI code smells appear when developers create unnecessary abstractions, such as a base class or interface that ends up with only one subclass, or write code paths that will never be executed. The recommended practice is incremental development: extract a superclass or interface only when a second subclass is required.

The above example shows unnecessary parent‑child classes that add maintenance burden without benefit.

Other YAGNI smells include dead code that is never reachable, classes that are subclassed without reason, public or protected members that could be private, and parameters or flags that always hold the same value.

These smells are easy to detect and can be removed with simple refactoring.

Use Comments or Not?

Good comments can be helpful, but they are not always beneficial. If you feel the need to comment, the code may need refactoring to become self‑explanatory.

When comments are necessary, they should explain the intent behind a piece of code, not restate what the code does. Examples of useful comments:

Explain why a particular implementation was chosen.

Warn future maintainers of potential pitfalls.

Declare assumptions that are not obvious from the code.

Justify deviations from standard practices.

Conversely, avoid comments that merely repeat the code logic.

Introduce explanatory variables, extract methods, use descriptive naming, and add validation checks instead of commenting out assumptions.

Effective Code Review Practices

Code reviews may slow down individual changes but improve overall code quality. Aim to get most changes approved in the first round with minimal issues.

Re‑evaluate your code before opening a review. Do not submit immediately after tests pass; take a step back and consider if the design can be cleaner.

Consider an informal design discussion. Use pair programming or early feedback to surface design concerns.

Perform a self‑review. Look at the code as if you were unfamiliar with it, using the review tool’s different view.

Make changes easy to understand. Submit small, focused changes rather than large, monolithic ones.

Do not hide important information in commit messages. Include essential context directly in the code.

When addressing review feedback, fix the most serious issues first, then re‑evaluate the code. Iterate as needed, improving naming, extracting methods, or adding concise comments to make the code clearer for future readers.