Coding Style

Trailing Whitespaces

This is one of the worst coding style error that there is! At least that's what they tell you when you are a rookie coder in companies like Amazon or Google and so on. It should always be kept in mind that whatever code you write, people will be collaborating with you and will most likely change things in your code. If the guy who just got handed your code to work on has to clean up your trailing whitespaces as the first job then certainly his expression will be of a frown and not awe for your clever use of data-structures.

So please avoid trailing whitespaces at any cost! You can use code formatters to arrange your code neatly and avoid having those whitespaces before committing your code. Here is an example of using default code formatter in Eclipse.

Tabs Vs. Spaces

This is a much debated topic about coding style. Although most people prefer to put equivalent number of spaces (either 4 or 8. Exactly how much is a topic of debate which is older yet!). In some enterprise development environments they even insist on it. One of the chief reasons behind this is since most of the code written today is targeted to be multi-platform-compatible code, each platform will interpret a tab differently. Result of this would be an incomprehensible code on certain systems which is certainly no joy to look at! This project follows 1 Tab == 4 Spaces convention.

Organizing Imports in Java code

Though unused imports don't eat up any memory, it is not a nice gesture to have them lying around in your code. It is a common scenario that one uses some library or data-structure initially only to replace them later with better libraries or data-structures. In such cases though it is prudent to use IDEs to clean up the initial import statements just as they conveniently inserted them in. For example, in Eclipse IDE Ctrl + Shift + O would do the job! (Google around for similar such shortcuts for IDEs of your choice.)

Again arranging used imports in a neat manner is also a very good thing to do. Consider following code -

import java.util.List;
import com.bits.protocolanalyzer.analyzer.PacketWrapper;
import com.bits.protocolanalyzer.analyzer.PcapAnalyzer;
import com.bits.protocolanalyzer.repository.LinkAnalyzerRepository;
import com.bits.protocolanalyzer.repository.NetworkAnalyzerRepository;
import org.springframework.web.bind.annotation.RequestMapping;
import com.bits.protocolanalyzer.repository.TransportAnalyzerRepository;
import com.bits.protocolanalyzer.input.PcapFileReader;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Controller;
import org.springframework.web.servlet.ModelAndView;

versus,

import java.util.List;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.servlet.ModelAndView;

import com.bits.protocolanalyzer.analyzer.PacketWrapper;
import com.bits.protocolanalyzer.analyzer.PcapAnalyzer;
import com.bits.protocolanalyzer.input.PcapFileReader;
import com.bits.protocolanalyzer.repository.LinkAnalyzerRepository;
import com.bits.protocolanalyzer.repository.NetworkAnalyzerRepository;
import com.bits.protocolanalyzer.repository.TransportAnalyzerRepository;

Clearly arranging import statements in the second way gives a more readable code.

Blocks of Curly Braces

Arranging code blocks within curly braces with correct indentation is one the most important parts in cultivating a good coding style. The practice followed by this project is as follows -

if (condition) {
    //code
}

The same goes for other blocks like while, for and do-while

Some coders like the opening curly brace just down the if statement which is also fine in my opinion. One can also argue that it looks better than the first choice but a vast amount of java code in terms of different software and libraries is already written using the first choice. Hence it will be good to follow the same practice.

Avoiding Null Pointer Exceptions

As described here, using null in many cases is not a good idea. But in some cases they do pop up and so do NPEs at the run time. Unlike most other exceptions, NPEs have potential to take down entire application. So whenever performing any operations on collections, take special care to avoid NPEs.

Also for such checks don't code it like this -

if (null != myList && !myList.isEmpty()) {
    // do stuff
}

Rather use null safe checks like those in Apache CollectionUtils library.

One last tip to avoid potential NPE in a situation where you are comparing two variables neverNull_A and couldBeNull_B then instead of this -

if (couldBeNull_B == neverNull_A) {
    //do stuff
}

write

if (neverNull_A == couldBeNull_B) {
    //do stuff
}

Believe me. This practice will save a lot of time in debugging application failure.