Custom accessors with IntelliJ's new code generation features

The problem with getters

If you know your Java history, you will also be familiar with the naming conventions for accessors and mutators that was introduced, and defined, by the JavaBeans specification. (i.e. the good ol' getters and setters) This naming convention became more or less a de facto convention for accessor and mutator methods in Java. Even for objects that had no intentions whatsoever to be a java bean.
And because it was such a widespread naming convention many frameworks and libraries started to rely on that convention in order to provide useful features. Luckily, many of the popular frameworks and libraries that are used today no longer require these naming conventions in order to function.

That means that today it is perfectly fine to write code like person.name() if it makes more sense to you and you will not be forced to write person.getName() just in order to get your tooling to work.

Clean code - why it matters

Well designed and thought through code is something every software professional should take seriously as it is an enabler for so many important properties of software design. It will help you in areas such as testability, maintainability, modularity, sustainability, readability, security, time-to-market and so on. The list of positive side effects of creating well designed code is neverending.

If you are new to the term clean code, then Bob Martin's book Clean Code is a good place to start to get an inroduction to what it means. In his book, Bob Martin shows many examples of what clean code can look like and you may not agree with all of them but the importance is to understand the overall concept and purpose of the term. Other areas to explore in terms of code design is domain driven design (DDD) and test driven development (TDD).

In my view, well designed code is the foundation of everything that we do as software professionals. All contemporary best practices that we apply daily are dependent of well designed and expressive code. Whether it be TDD, DDD, domain driven security, continuous integration, scalability and so on. A poorly designed code base that is nothing more than a big mess of code will never enable you to succeed in any best-practice, at all. Period. This may sound a bit harsh but in the long run I really do believe that well designed code is the base for everything else.