Establishing coding guidelines is one of the main task for Technical Lead or the Technical Architect for any newly starting project. This is one of the ritual which attracts very little attention form both developers & management.In past I have tried to set up coding standards for J2EE based projects & came up with guidelines for each layer (Service, DAO & Presentation).Although it was well advertised, most of the developers did not even seem to interested in looking into the content & were happy to follow the prototype. In that sense establishing a coding guidelines is the least impressive job & probably the most thankless job.
With this background, I started looking into the existing published coding guidelines with the intention of extracting best of all the published guidelines. Surprisingly Sun published java coding guidelines in 1999 & never thought it to be worth revising.I also looked into the other big java shops like IBM,eBay,BEA & Oracle, I couldn't find any content that focuses solely on coding guidelines (Please correct me if I am wrong on this).
Most of the information I found on coding guidelines was repetitive. With Java replacing C,C++ as primary computer learning language & with best IDEs taking care of indentation, style etc... there is no need to have full fledged coding guidelines & I guess Sun is right in not revisiting their coding guidelines document. So coming up with Java coding standards doesn't make sense, the best option would be come up with Technology centric coding guidelines (SWING, EJB ,Spring, custom framework etc...) to really have some value addition in this area.
So I am enumerating few topics here that I have observed over the years while writing Java code & mentoring programmers. I guess the that's the better option than coming up with a clone of sun coding standards by changing some content here and there.
These are some mistakes (or bad practices from Java point of view) I found with the guys coming from C++ background & junior engineers in my experience:
1. Method name starts with capital letter (Like GetThis() etc..)
2. Passing reference & manipulating them (Writing methods like void getData(SomeObject obj) etc...)
3. Very conservative about writing many methods & classes (over cautious about the performance)
4. Poor understanding of abstraction
5. Writing lot of static methods
I think best way to understand the Java coding standard is by going through the source code of JDK.
Objective of coding standards:
- Creating concise code
- Improve readability, maintainability & continuity (Programmers changing over the time should have least impact)
So although it is trivial, it is important for the organization to enforce the coding guidelines strictly(Sun java guidelines).
List of some good Coding Guideline links:
Sun Java Code Conventions
Coding standards from nejug
Standard Java coding guidelines -This I found it very interesting as it was trying layout the guidelines on OO principles.
I am planning to come up my own standards some time in future.:)
I really liked the idea of Google where they have listed out only the missing information from Sun standards, This is the approach I am going to suggest for my future projects as well.
The most important point I feel in writing the good quality code is considering the good design principles & have them as part of coding checklist.I have also published some points on presentation layer in one of my previous blog.
Here are my favorite picks:
1. Handling NullPointerException
This is most disgraceful error that a programmer can make, I always used to treat this exception as insult the programmer's intellect. Before calling any methods programmer needs to ask himself a question "Hey can this be Null" if he thinks it can be a null, then putting Null check is also not always correct. I personally hate null checks in the code. Most of the time it is like looking at both side of the road while crossing a one way road.
So I prefer throwing IllegalArgumentException & usage of assert keyword
2. Exception Handling
Spring, Hibernate & other popular frameworks have established one fact that Checked Exception are over-used & Runtime exceptions offers best solutions in most of the cases. Although James Gosling hails Checked Exception or Fault containment as one of the best feature of Java I tend to agree with usage of Runtime Exceptions heavily with the caviet that if there is alternate flow that API user can handle or we are writing APIs & exposing them to third part checked Exceptions are the best.
All the Exception that happen very rarely & is because of hardware/network or programmatic errors which end user can't really help should be declared as RuntumeExceptions & any checked exception thrown by other APIs should be declared in throws bloc if we can't take any action in the try{}catch{} bloc.Exception should be thrown only in case of alternate flows.FinderException is very bad design in EJB as it throws Exception if there are no records rather than returning empty list, that's silly.
With the above stated principle RemoteEception should have been RuntimeException & ParseException (For example Integer.parseInt(String str) is likely to go wrong should have been Checked Exception.
3. Usage of proper APIs
There are quite lot of hidden gems of Java that are under-utilized, Like java reflection, WeakHashMap & lazyloading with Runnable can really make applications more faster and robust. Spending time Javadocs is most useful exercise.
We need tools to correct the mistakes, We need to make static analyzers intelligent enough to take care of all the unit testing issues & performance issues. Tools like PMD offers the huge benefits in terms of productivity and improving the quality of code. The plug-ins available for popular IDEs like NetBeans, eclipse makes developer life still simpler.
PMD rules Index - There are about 200+ PMD rules for code checking.As prevention is better than cure, it always better if developer visits these before writing code.
Here are my best rule that can be used as mandatory ones
Unused Code Rules
Basic Rules
Optimization rules
Strict Exception Rules
Import Statement Rules
These rules also can be considered
Design Rules
Type Resolution Rules
Code Size Rules
Some bad rules;
AtLeastOneConstructor
CallSuperInConstructor
LongVariable
ShortVariable
I fully agree with this link on PMD Bad Rules.
Hammurapi,CheckStyle and Findbugs also provides similar rules, It will be good exercise to extract best out of all these.
Finally,
All the rules, Conventions & best practices are here to help us. We definitely not here to help these rules. Common sense should prevail over these guidelines. Consider what you like & disdain what you don't like.
