Rethinking Imports, Interfaces, and Common Coding Rules: When Best Practices Miss the Mark

Import classes, not whole packages

In many languages this is a recommended practice, and in some it is even required. In C++ it can slightly speed up compilation for very large projects, but the benefit is limited.

For languages like Java, the practice brings no compilation speed advantage; it merely adds effort to maintain import statements. IDEs can automate this, but developers still need to make occasional manual adjustments, creating extra version‑control noise without real benefit.

Programming to Interfaces

This rule asks programmers to define interfaces and code against them rather than against concrete implementations. The rationale is simple: it eases the creation of alternative implementations, facilitates testing, and promotes more effective code reuse.

However, applying the rule universally can be counterproductive. If a method does not require multiple implementations, forcing an interface adds unnecessary code and complexity. Refactoring a class into an interface later is straightforward, so premature interface creation is often unwarranted.

Disabling Certain Language Features

Many coding standards forbid constructs such as goto statements or ternary operators. If a language feature is not deprecated, why ban it? Proper use can improve readability and understanding, provided it is applied in the right context.

Use Setters/Getters, Prohibit Public Fields

This is a classic Java style: public fields are discouraged; all fields should be accessed via setters and getters. The author questions whether this practice truly prevents accidental modifications or merely inflates code size.

Single Return Statement

Some argue that multiple return statements complicate code. In many cases, a single return can actually make a function harder, requiring extra if‑else blocks to handle error paths.

Strive for Responsibility Separation

While breaking a large problem into smaller pieces is beneficial, over‑splitting can create a proliferation of trivial components that add maintenance overhead. Not every complex issue can be simplified by decomposition.

Do everything with a clear reason.

If the result does not meet expectations, redo, replace the method, or apply a fix.

Discard wasteful code, regardless of its perceived value.

English: AURISC4 BLOG Translation: External IT Review Link: http://www.vaikan.com/programming-best-practices-i-disaprove/