Fundamentals of Java Coding Standards

Here we are going to discuss some standards to practice coding in Java.

Why do we need it?

Generally, people refer that there are so many developers who will work on the same project. During the progress of the project, new team members will join the project. Meanwhile working team members may leave the project or may leave the company as well. At some point of time, if there is a bug to fix in the code that had written by the former team member, the team should fix it. To fix it, people have to read it. When they read that code, they should understand every line of code in a single shot. This doesn't mean that we have to mention comments in every line explaining the line of code. We have to follow some basic standard coding This makes their work easy. There is a line saying that “Good programmers will write human-readable code”.

1. Naming conventions
   Every name that we use is self-explanatory whether it is a variable, method, class, interface, package, etc. A name must reveal its intention, what it is meant for, so everyone can understand and change the code easily.

• Class and interface names should be nouns, starting with an uppercase letter. If there are multiple words in the name, each word should start with a capital letter. Examples: Student, Car, ShoppingMall, NoteBook, etc.
• Variable names should be nouns, starting with a lowercase letter. If there are multiple words in the name, each word should start with a capital letter. Example: birthDate, name, gender, etc.
• Method names should be verbs and self-explanatory what that method will do. Starting with a lowercase letter, and if there are multiple words in the name, each word should start with a capital letter just like a variable naming convention. Example: getElementById, executeQuery, fetchAllUsers, substitute, etc.
• Constant names should have all UPPERCASE letters and words are separated by underscores. Examples: MAX_STRENGTH, MIN_PRIORITY, MAX_PRIORITY, etc.
• Package names should always be in lowercase in order to avoid collisions with classes and interfaces. It should be unique for the entire project. Examples: com.airtel.services, com.bsnl.services, com.jio.services, etc.

2. Ordering of data members of a Class
When it comes to ordering members of a class, different people will have different perceptions.
Some people will say order the data members based on the data type of a member variable. If there multiple variables with the same data type, then order them based on alphabetical order.

class Student {
   private String email;
   public final String firstName;
   public final String lastName;
   private String final usn;
   
   protected float percentage;
   
   protected List<Project> projects;
   }

Some people will say order the data members based on the scope of the variables. Variables should be ordered by increasing their scope i.e private, default, protected, and public.

class Student {
   private String final usn;
   private String email;
   
   protected List<Project> projects;
   protected float percentage;
   
   public final String firstName;
   public final String lastName;
}

Personally, I will suggest following the first approach because most of the time data members of a class are either default or private. As a programmer mostly we will concern about the data type of a variable rather than the access modifier of a variable.

3. Initialization of default values for the field variables
We should never initialize default values for the field/instance/data variables because they are assigned by JVM to field variables by default. If we assign default values it may create unnecessary confusion sometimes.

4. Declaring constants
Never ever use interfaces to declare constant values because interfaces are meant for polymorphism and standardization. Instead, use a class or enum to do this type of constants declaration.

5. Looping
Try to avoid using the traditional way of using conventional for loops using loop index variables unless it is unavoidable. Instead, make use of enhanced forEach loop.

6. Blank Lines
Oracle itself suggesting some scenarios where we can make use of blank lines to improve readability.

Two blank lines should always be used in the following circumstances:

• Between class and interface definitions

One blank line should always be used in the following circumstances:

• Between methods of a class
• Between the local variables in a method and its first statement comment
• Between logical sections inside a method to improve readability
• Give a line break between lines of a code to group the code of a particular operation.

7. Single statement for single line

argv++;          // Correct
argv = argv + 1; // Perfect
argv++; argc--; // Avoid

8. Return statement should not use parathesis.

9. Mention curly braces for blocks even if there is no implementation.

if (condition) {
}

10. Some people suggest that to prefix Abstract for abstract classes, Interface for interfaces, suffix Servlet for servlets, DAO for classes dealing with the database. Some people even suggest that to suffix implInterfaceName to indicate that class is an implementation of an interface.

I think I have done with basic standards to code in Java. There are many more standards that we can follow. I will insist you figure it out yourself.

You can refer to Oracle Code Conventions for the Java Programming Language for more details. You can refer to any other source you are comfortable with.