Style has an important role when it comes to writing clean, readable code. Conforming to conventions and best practices is a good starting point. In addition to that there is still plenty of room for choice. Those depend greatly on the level of the developers and personal preferences.
There is a very specific danger with conventions and best practices. Most of them are distilled experience of the industry and are there for good reasons. Some of them may be questionable but are rarely - if ever - questioned. They get incorporated into the coding style and without conscious effort to pinpoint them become invisible. I think all developers should investigate their code from time to time and inspect even the most trivial elements for such issues.
A couple of things that I think are worthy to look at:
Getter/setter methods
Since IDEs can generate them so easily, these are very often abused. Some developers have the habit of generating them right away, throwing away the most important element of object oriented programming - encapsulation - without further thought. Mutators are created on objects that could be immutable. The get...() prefix is often meaningless, and actually harms readability:
person.getName();
person.getAddress();
person.getMobileNumber();
person.name();
person.address();
person.mobileNumber();
Constant naming conventions
The convention is to use uppercase names which can be quite unreadable - especially if there are many long-named constants in a class. Unless it's part of the api, the fact that a field is constant is an implementation detail.
Final keyword on local variables
Some static code analyis tools show warnings when local variables are not marked as final - if they've been assigned only once. While it adds value in many cases, if applied on all local variables without reason, the clutter it introduces can make the code harder to read. One can argue their constant use is good in long and complex methods, but in my opinion the problem is having such methods in the first place.
Exception suffix
A really controversial one, but I think it's worth to at least toy with the idea. Almost all exceptions have the ...Exception suffix in their names. This is actually not really necessary and it does add some noise. Note that in whatever context we encounter an exception, the syntax makes it already obvious:
- Definition of an exception - Something extends Exception
- Throwing an exception - throw new Something
- Declaration of an exception thrown - throws Something
- Catching an exception - catch(Something)
Dropping the suffix can work on exceptions that are named as events, not just plain nouns (which is btw a useful practice on it's own right). Compare FileNotFound vs FileNotFoundException. It can be interesting to see it's effect in a codebase. Some libraries do this, eg javassist, bouncycastle.
Anyways - no absolute truth or silver bullets here. Just some food for thought.
