Coding practice and conventions in Java

Anyone can write code a computer can understand, but professional developers write code *humans* can understand. Clean code is a reader-focused development style that produces software that's easy to write, read and maintain.

I have seen code written for the products which are serving more than 2 dozen clients with single database and 1 codebase. This is amazing. The reason they were successfully managed to do so was because of the coding standards they follow. The use of standard coding practice in your project makes life easy. 

If you set your standards very much in the beginning before you actually start coding for a product, it will become the rule for the fellow developers and makes life earsier for the new comers and the coders who have to decode you wrote in the beginning.

Having standards gives you the checkpoints to identify if a developer writing a quality code or not. 

https://amzn.to/2wKFA4y

Also code conventions are important to programmers for a number of reasons:

• 80% of the lifetime cost of a piece of software goes to maintenance.
• Hardly any software is maintained for its whole life by the original author.
• Code conventions improve the readability of the software, allowing engineers to understand new code more quickly and thoroughly.
• If you ship your source code as a product, you need to make sure it is as well packaged and clean as any other product you create

I will try to cover all possible and important part of java standards in following sections.

 Java Source files

Beginning comments

All source files should begin with a c-style comment that lists the class name, version information, date, and copyright notice:

/*
 * Classname
 * 
 * Version information
 *
 * Date
 * 
 */
 * Copyright notice

Package and Import statements

The first non-comment line of most Java source files is a package statement. After that, import statements can follow. For example:

package java.awt;

import java.awt.peer.CanvasPeer;

Indentation

Line length

Avoid lines longer than 80 characters, since they're not handled well by many terminals and tools.

Wrapping Lines

When an expression will not fit on a single line, break it according to these general principles:

1. Break after a comma.
2. Break before an operator.
3. Prefer higher-level breaks to lower-level breaks.
4. Align the new line with the beginning of the expression at the same level on the previous line.
5. If the above rules lead to confusing code or to code that's squished up against the right margin, just indent 8 spaces instead.

Examples:

Here are some examples of breaking method calls:


someMethod(longExpression1, longExpression2, longExpression3,
        longExpression4, longExpression5);

var = someMethod1(longExpression1,
                someMethod2(longExpression2,
                        longExpression3));

Following are two examples of breaking an arithmetic expression. The first is preferred, since the break occurs outside the parenthesized expression, which is at a higher level.

longName1 = longName2 * (longName3 + longName4 - longName5)

           + 4 * longname6; // PREFER

longName1 = longName2 * (longName3 + longName4

                       - longName5) + 4 * longname6; // AVOID 

Following are two examples of indenting method declarations. The first is the conventional case. The second would shift the second and third lines to the far right if it used conventional indentation, so instead it indents only 8 spaces.

//CONVENTIONAL INDENTATION

someMethod(int anArg, Object anotherArg, String yetAnotherArg,

           Object andStillAnother) {

    ...

}

//INDENT 8 SPACES TO AVOID VERY DEEP INDENTS

private static synchronized horkingLongMethodName(int anArg,

        Object anotherArg, String yetAnotherArg,

        Object andStillAnother) {

    ...

}

Line wrapping for if statements should generally use the 8-space rule, since conventional (4 space) indentation makes seeing the body difficult. For example:

//DON'T USE THIS INDENTATION

if ((condition1 && condition2)

    || (condition3 && condition4)

    ||!(condition5 && condition6)) { //BAD WRAPS

    doSomethingAboutIt();            //MAKE THIS LINE EASY TO MISS

} 

//USE THIS INDENTATION INSTEAD

if ((condition1 && condition2)

        || (condition3 && condition4)

        ||!(condition5 && condition6)) {

    doSomethingAboutIt();

} 

//OR USE THIS

if ((condition1 && condition2) || (condition3 && condition4)

        ||!(condition5 && condition6)) {

    doSomethingAboutIt();

}

Here are three acceptable ways to format ternary expressions:

alpha = (aLongBooleanExpression) ? beta : gamma;  

alpha = (aLongBooleanExpression) ? beta

                                 : gamma;  

alpha = (aLongBooleanExpression)

        ? beta 

        : gamma;

Declarations

Number Per Line

One declaration per line is recommended since it encourages commenting. In other words,

  int level; // indentation level

  int size;  // size of table

is preferred over

  int level, size;

Do not put different types on the same line. Example:

  int foo,  fooarray[]; //WRONG!   

The examples above use one space between the type and the identifier. Another acceptable alternative is to use tabs

Initialization

Try to initialize local variables where they're declared. The only reason not to initialize a variable where it's declared is if the initial value depends on some computation occurring first.

Placement

Put declarations only at the beginning of blocks. (A block is any code surrounded by curly braces "{" and "}".) Don't wait to declare variables until their first use; it can confuse the unwary programmer and hamper code portability within the scope.

Class and Interface Declarations

When coding Java classes and interfaces, the following formatting rules should be followed:

No space between a method name and the parenthesis "(" starting its parameter list

Open brace "{" appears at the end of the same line as the declaration statement

Closing brace "}" starts a line by itself indented to match its corresponding opening statement, except when it is a null statement the "}" should appear immediately after the "{"

class Sample extends Object {

    int ivar1;

    int ivar2;

    Sample(int i, int j) {

        ivar1 = i;

        ivar2 = j;

    }

    int emptyMethod() {}

    ...

}

Methods are separated by a blank line

Happy reading...