Java Programming Best Practices

Never trust the values returned by other exposed services. Always do a check on the values returned based on the scenario

Always check the pre condition. Make sure pre condition is always satisfied. Check for NULL always. like ask a question, if this argument is null what to do?

Understand which exception is a show stopper and which is not a show stopper. Throw back the exceptions that are show stoppers, log the exceptions that are not show stoppers.

Always explain the pre conditions and post conditions and exception scenarios of a method.

Don trust arrays that a are returned by other methods. Those arrays might contain null. So when the array is iterated it is better to check for null for each location.

If you are creating an array, and inserting values into it, check the scenarios for null.

If you want an array as the result of a method, but not sure of the size of the array during the creation array, then use arraylist. Once done create array from the arraylist.

While reading from property file, use propertyfile.getValue( key, default value). This saves us from checking null and spaces.

Don’t use StringBuffer if u r using ‘+’ to concatenate multiple String because Java will always write whatever String formed using + fully.

Try to initialize the StringBuffer with capacity. This will improve performance.

Any method u write, make it very small. use conditional operator to the max. This will make the code look clean.

Use regular expressions for checking some sub string within a string.

Inside a method always use temporary variables. Like for an array, if u r playing with array, use temporary array. This will increase performance.

Classes grow like a tree. Like if u have a main class , and u r calling other classes from main, like helper classes, the methods in main class should just call other methods, where by reading the method name, the functionality of the method should be understood. Helper classes and other classes can grow big. So its like a tree.

Utility class should be very generic. If same functionality to be achieved, but with different method, then use over loading in utility classes.

If u wanted to Convert some wrapper class to String, like to convert Long to String, never user new Long(12233).toString(). Instead user “”+12233 This increases performance

Always make the method names meaningful. Also the input arguments should be meaningful.

JUnit philosophy. When you run Junit test cases, always it should be green, No red. When testing negative conditions, the negative condition should pass. So it should be green.

Make a project in such a way that it should run after checking out from CVS and building it.

Never user kill -9 for stopping servers. use kill command only. Kill -9 is forced. It can leave many transactions open. This will some time cause problen during next start up

If any methods that take more than 2 minutes to understand then it is a tough logic.

Developer should be convinced with the logic and no confusion should be there for him

When you write any method, try to return void or boolean other than cases where you need to return some object and the calling method wants to do some processing with the same.

Void is good because it gives an impression that either the logic has exceuted successfully or and exception has occured.

For any DB calls, check the requirement for connection time out. Test it and implement it.

When to make the methods of class static ? Only if the instances of class has state. If the class only does some functionalities and don have any state then make the methods static

Object oriented programs should have life. See when u can use object orientation and when procedural

In any project, identify the most used use case, amount of time the use case takes to execute and number of transactions in each request send by each use case.

If the application being developed is hitting any other servers ( like data base server, mail server etc), always configure failover URL for these servers.

Always have goals in mind before doing the task. Then identify the steps to reach the goal.

When should a method throw an exception. Depends on what functionality the method implements. Ex: Suppose a user checks what balance is available in his account. If the available balance is zero, no exception needs to be throw.

But if user authentication fails, then exception can be thrown.


Defensive Programming

As Murphy’s Law states, “Whatever can go wrong, will go wrong”.

“If there’s more than one possible outcome of a job or task, and one of those outcomes will result in disaster or an undesirable consequence, then somebody will do it that way”.

So defensive programming is all about guarding one’s code. Never trust any external entities. So all the inputs that comes into one’s method should be scanned.

For example :
Consider this piece of java code.
public void myfun( String a, String b){
int i = a.length();
int j = b.length();

Here ‘a’ and ‘b’ can be null.
So in defensive programming it will be
if( a == null) return; if( b == null ) return;

Always be in safer side is the philosophy of defensive programming. This reduces the log debug statements as one can be sure that he has handled most of the conditions that will break his code.
Code written in this manner can be reused, since it won’t create any unnecessary bugs.

There are various techniques used in defensive programming.
Some are assertion, design by contact, return exceptions etc.