Java Coding Standards , WHY?

Himanshu Bhatt

4 min read

·

Sep 26, 2023

--

Listen

Share

Well if you are a beginner in programming , coding syntax ,time complexity logic itself seems like a flying cockroach ,when you finally have confidence of typing code like yes i learn how to code and how to type my logic.

i have a news for you ,when working in an organization you have to write code , BUT YOU HAVE TO WRITE GOOD CODE . and for writing good code we have some standards , few rules everyone must follow .

WHY CODING STANDARDS , WHAT DO YOU MEAN GOOD CODE ?

in simple words , we follow coding standards so the other persons/programmers can understand our code easily .

i read a quote that goes

ANY FOOL CAN WRITE CODE A COMPUTER CAN UDERSTAND , A GOOD PROGRAMER WRITE CODE 
THAT HUMANS CAN UNDERSTAND

First you will not manage that code your whole life , someone else have to work on it , second while adding and extending your code others should easily understand big codes with ease .

Why developers don’t do it ?

• Lack of knowledge base: This applies to starters or to junior developers who do not have much exposure to writing clean codes.
• Lack of motivation: This applies to a few developers who do not get much to do good work. They lack a work ethic.
• Lack of time: When developers are faced with tight deadlines, they may choose to focus first on solving the task and then on writing clean codes.

Writing poor codes may be faster in the short term but when we have taken time and effort into our code’s design, adding new features, fixing bugs, and collaborating with other developers becomes much easier.

So What are these standards ?

Naming Conventions

• Package names are typed in lowercase e.g. javax.sql, com.newpackage, java.lang. Some not preferable ones are e.g. com.newPackage, com.new_package.
• Class, enum, interface, and annotation names are typed in UpperCamelCase e.g. Thread, Runnable, Person.
• Constants are types in uppercase separated by an underscore e.g. SIZE, MIN_VALUE,MAX_VALUE.
• Methods names are verbs and are typed in a lowerCamelCase e.g. deleteCharAt(), add(), isNull().
• Variables are typed in lowerCamelCase e.g. employeeName, birthDate, email. The name should be short and such that it tells the reader of the program what this variable stores.

Commenting Codes

One Friday you leave your code thinking you will finish it next Monday , but trust me you will surely have problem in understanding that code , so comment the code step by step so you can understand later .

Variable Declaration

• It’s recommended to declare one variable per line. This makes it easier to add comments and improves code clarity.
• For static or class variables, arrange them in this order: public, protected, and then package/default (no modifier). Next, define class constructors and inner classes if needed.
• Avoid using the same variable name in nested blocks that’s already declared globally. Local variable declarations should come at the beginning of blocks. Don’t directly code numerical constants.

Source File Organization:

• Each Java source file should contain only one class or interface, and each class must be in a separate file.

int studentId,totalMarks;    // Avoid

// Preferred
int studentId;
int totalMarks;

• Try to limit the number of parameters in a class to 12.
• Avoid lines of code that extend off the screen. Break long expressions after commas or operators.
• Use blank lines to group logically related sections of code for improved readability.
• Numerical constant should not be coded directly.

// Avoid
String name = personsById.get(2906);

// Preferred
final int PERSON_ID = 2906;
String name = personsById.get(PERSON_ID);

• All source files should include a documentation comment with information like title, version, date, author, etc. This should be followed by a package declaration and a class comment.

FUNCTION GUIDELINES

The starting brace ({ ) should be at the end of the same line as the declaration statement or method and the ending brace (} ) must be on a separate line and aligned with the conditional/class.

// Preferred
public class ABC {
  // codes
}

// Avoid
public class ABC
{
  // codes
}

All binary operators except “.” should be separated from operands using a space. For example, int value = a + b + 1; is preferred overint value=a+b+1;

OTHER

• We should not document overrided method unless the implementation has changed.
• Do not omit braces {} in conditionals. Wrap logical similar conditions and use proper indentations where ever applicable so that all statements are easy to read.

// Avoid
if (condition) 
  statement;// Avoid 
if (x < 0) function(x);// Preferred
if (condition) {
   statement;
}// Preferred
if ((a == b) && (c == d)) {
    ...
}

In switch cases always have a default case even without code. Every time a case falls through (doesn’t include a break statement), add a comment /* falls through */ where the break statement would normally be.

switch (condition) {
case ABC:
    statements;
    /* falls through */
case DEF:
    statements;
    break;
case XYZ:
    statements;
    break;
default:
    statements;
    break;
}

Messages should be properly indented and organized such that they are easy to read

// Preferred
throw new CustomException("Failed to retrieve"
    + " request " + request.getId()
    + " for user " + user.getId()
    + " query: '" + query.getText() + "'");

Conclusion

many IDEs such as IntelliJ or Eclipse already provide code formating options , VS Code have extensions like Prettier for code formating.

But we still need to add comments as they are not yet smart enough to also do that for us! Anyway, the take away is that we should write code in such a way that makes the life of future authors and maintainers easy.