Why Inconsistent Naming Breaks Java Projects and How to Refactor It

Inconsistent Naming in a Java Project

Many teams end up with different naming styles for similar concepts, such as using DAO , Mapper , or Repository interchangeably. The article shows an enum with values WEBSITE and KINDLE_ONLY , explaining that they represent publishing channels (website vs. Kindle store) but are named inconsistently, leading to confusion.

It argues that similar meanings should share a unified name, just as business services are commonly named XXXService . Inconsistent names often indicate different semantics, for example BookSender for sending a work to a translation engine.

Old Date‑Handling Code vs. Java 8 API

The original code creates a new SimpleDateFormat instance for each request to format a timestamp, which works but uses a pre‑Java‑8 approach. The article points out that the project already targets Java 8, so the modern java.time API should be used consistently.

Because the project mandates the new date‑time API, the old SimpleDateFormat usage is technically correct but breaks the team’s consistency rule.

Refactoring suggestion:

String timestamp = LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyyMMddHHmmss"));

Multiple Solutions and the Need for Standards

The article highlights that having several ways to solve the same problem—such as using Guava or Apache Commons Lang to check for empty strings—creates inconsistency. It stresses the importance of agreeing on a single approach to avoid “each‑person‑their‑own” implementations.

Refactoring Guidelines: Separate Concerns

By distinguishing business actions from low‑level details, the code can be reorganised. For example, the function that fetches an approved work and then builds an HTTP request to create the work in a translation engine mixes two concerns. The article proposes splitting it into:

Fetching the approved work (business action).

Building request parameters (detail).

Sending the request (detail).

These steps can be moved into separate methods or even a new model class, improving readability and testability.

Overall, the article demonstrates that clear naming, consistent use of modern APIs, and strict separation of concerns are essential for maintainable backend code.