This journal entry consolidates the best practices and recommendations of the Java developers community gained from the past years of language use.
Java Coding Convention – Rules
Rule #1
a) Don’t use the wildcard character in package import statement. Always use the qualified name of the package with the import statement.
Example:
import java.io.* //Wrong Statement import java.io.file //Correct Statement
b) Import statement should be alphabetically sorted, separated in groups with a blank line.
.static import
.java, .javax, then org and com packages
.others imports
Example:
import static java.lang.Math.min; import java.io.File; import java.io.FileReader; import javax.servlet.GenericServlet; import org.springframework.context.ApplicationContext; import com.google.gwt.user.server.rpc.RemoteServiceServlet; import backtype.storm.tuple.values;
Rule #2
One class per file. The name of the file must be the same as the class name.
Rule #3
Avoid deep Nesting: Too many levels of nesting makes the code harder to read and follow.
Rule #4
Class names should be nouns unless you have a good reason for it not to be a noun. First letter of the class name should be in capital letter.
Example:
class DevelopersJournal {
// Code goes here....
}
Rule #5
Name of the methods using verb-object pair, such as readJsonFile()
Rule #6
Methods or functions returning a boolean type should generally start with a verb is, or alternatives that fit better in some situations like has/have, can or should, etc.
Example:
isValid(); or isOpen();
Rule #7
a) Variables should be named so that they make it clear what it contains. Variable names should always be easy-to-read, be short yet meaningful, mixed case with a lowercase first letter English words.
b) Use plural names for arrays/collections of objects.
c) Constant (static final) variable names should be in all capital letters and separate words in the name with the underscore, i.e., PRIORITY_NORMAL
Java Clean Code – Rules
Rule #1
Keep your piece of code where it belongs. Classes should be placed in the proper package name and methods to their appropriate classes.
Rule #2
Methods should follow the principle of Keep It Short and Simple (KISS). Functions should have a single responsibility, i.e., a function should do one thing. Avoid using boolean arguments because they cause confusion. Boolean (flag) arguments loudly declare that the function does more than one thing.
Rule #3
Avoid OS dependent behavior, e.g., Unix-centric constants “\n”, “/”, etc.
Rule #4
Explicitly declare all field types as private and provide a public get and set method to read and write properties. This restricts the direct access to properties and fields and using get and set you can validate your data.
Rule #5
Declare a local variable as close as possible to its first use.
Rule #6
You should document all of your methods even the private ones if they are complex.
Rule #7
Every class created should be inside a package where it belongs.
Rule #8
Private class variables should have underscore suffix. Underscore nicely resolves the problem of finding reasonable variable names for setter and getter methods.
Example:
private String _name;
void setName(String name) {
this._name = name;
}
Rule #9
The term compute can be used in methods where something is computed. Example:valueSet.computeAverage();
Rule #10
Array specifiers must be attached to the type not the variable.
Example:
int arrayInt[] = new int[10]; // Wrong int[] arrayInt = new int[10]; // Right
Summary
By following the above-specified Rules for coding conventions and clean code, the developers like you and me can simplify our life. These not only help in writing an error free code but it also helps in better understanding once we try to come back to our code after a long time of writing.