Appendix A - Conventions Rules

3. 2. J2EE Naming Conventions Rules

Java Naming Conventions Rules

Overview

Table A.1. Java Naming Conventions Overview

JAN_001: Match A Class Name With Its File Name (High)

Checks whether the public class and interface has the same name as the file in which it resides.

WRONG

/**
 * Copyright Notice
 *
 * Filename: FooAutitor.java
 */
public class Foo {
}

RIGHT

/**
 * Copyright Notice
 *
 * Filename: FooAutitor.java
 */
public class FooAutitor {
}

JAN_002: Group Operations With The Same Name Together (Low)

Enforces standard to improve readability.

WRONG

package be.vlaanderen.myproject.subpackage;

public class Foo {

    void operation() {
    }

    void function() {
    }

    void operation(int param) {
    }
}

Tip Group operations that differ only by their parameter list together. Good to order from least number of parameters to most.

RIGHT

package be.vlaanderen.myproject.subpackage;

public class Foo {

    void operation() {
    }

    void operation(int param) {
    }

    void function() {
    }
}

JAN_003: Use A Correct Name For A Class Or Interface (Enforced)

Class and interface names must contain only letters and start with an upper-case letter (See JLANGSPEC - section 6.8.2).

WRONG

class _Foo {
}

RIGHT

class Foo {
}

JAN_004: Use A Correct Name For A Non Final Field (Enforced)

Non-final field names that are not constants should contain only letters, starting with a lower-case letter (See JLANGSPEC , Section 6.8.4).

WRONG

int BAR = 100;

RIGHT

int bar = 100;

JAN_005: Use A Correct Name For A Constant (Enforced)

Names of constants (final fields that are assigned a constant value) should contain only upper-case letters and underscores (See JLANGSPEC - section 6.8.5). Makes Java code easier to read and maintain by enforcing the standard naming conventions.

WRONG

static final int bar = 100;

RIGHT

static final int BAR = 100;

JAN_006: Use A Correct Name For A Method (Enforced)

Method names should contain only letters, starting with a lower-case letter (See JLANGSPEC - section 6.8.3). Makes Java code easier to read and maintain by enforcing the standard naming conventions.

WRONG

int Foo(int x) {
    // ...
}

RIGHT

int foo(int x) {
    // ...
}

JAN_007: Use A Correct Name For A Package (Enforced)

Package names should contain only lower-case letters. Makes it easier to view a directory listing and be able to differentiate packages from classes. The package name can also not start with java or sun. Package names beginning with javax should also be avoided.

WRONG

package be.vlaanderen._myproject.subpackage;

RIGHT

package be.vlaanderen.myproject.subpackage;

JAN_008: Name An Exception Class Ending With Exception (High)

Names of classes that directly or indirectly inherit from java.lang.Exception or java.lang.RuntimeException should end with Exception.

WRONG

class AuditEx extends Exception {
}

RIGHT

class AuditException extends Exception {
}

JAN_009: Use A Conventional Variable Name When Possible (Normal)

One-character local variable or parameter names should be avoided, except for temporary and looping variables, or where a variable holds an undistinguished value of a type. Conventional variable names are:

b for a byte

c for a char

d for a double

e for an Exception

f for a float

i, j or k for an int

l for a long

o for an Object

s for a String

in for an InputStream

out for an OutputStream

To avoid potential conflicts, change the names of local variables or parameters that consist of only two or three uppercase letters and coincide with initial country codes and domain names, which could be used as first components of unique package names.

WRONG

void foo(double d) {
    char s;
    Object f;
    String k;
    Object UK;
}

RIGHT

void foo(double d) {
    char c;
    Object o;
    String s;
}

JAN_010: Do Not Use $ In A Name (Enforced)

Do not use the character $ as part of any identifiers (even though the Java Language Specification allows this).

WRONG

String buffer$1;

JAN_011: Do Not Use Names That Only Differ In Case (High)

Names that only differ in case makes it difficult for the reader to distinguish between e.g. anSQLDatabase and anSqlDatabase.

JAN_012: Make A Constant private Field static final (Normal)

private attributes that never get their values changed should be declared final. When you explicitly declare them like this, the source code provides some information to the reader about how the attribute is supposed to be used.

WRONG

public class Foo {
    private int attr1 = 10;
    private int attr2 = 20;

    void bar() {
        attr1 = attr2;
        logger.info(attr1);
    }
}

RIGHT

public class Foo {
    private static final int ATTR2 = 20;
    private int attr1 = 10;

    void bar() {
        attr1 = ATTR2;
        logger.info(attr1);
    }
}

JAN_013: Do Not Declare Multiple Variables In One Statement (High)

You should not declare several variables (attributes and local variables) in the same statement. If you define multiple attributes on the same line you won't be able to provide javadoc information for each of the attributes.

WRONG

public class Foo {
    private int attr1;
    private int attr2, attr3;

    void bar() {
        int var1;
        int var2, var3;
    }
}

RIGHT

public class Foo {
    private int attr1;
    private int attr2;
    private int attr3;

    void bar() {
        int var1;
        int var2;
        int var3;
    }
}

JAN_014: Use A Correct Order For Class Or Interface Member Declarations (Normal)

According to Sun coding conventions, the parts of a class or interface declaration should appear in the following order:

1. Class (static) variables. First the public class variables, then the protected, then package level (no access modifier), and then the private.
2. Instance variables. First the public class variables, then the protected, then package level (no access modifier), and then the private.
3. Constructors
4. Methods

WRONG

public class Foo {
    public void bar() {
    }
    public Foo() {
    }
    public static void main(String[] args) {
    }
    private int bar;
    private static Logger logger =
            Logger.getLogger(Foo.class.getName());
}

RIGHT

public class Foo {

    private static Logger logger =
            Logger.getLogger(Foo.class.getName());

    private int bar;

    public Foo() {
    }

    public void bar() {
    }

    public static void main(String[] args) {
    }
}

JAN_015: Use A Correct Order For Modifiers (enforced)

Checks for correct ordering of modifiers:

For classes: visibility (public, protected or private), abstract, static, final.
For attributes: visibility (public, protected or private), static, final, transient, volatile.
For operations: visibility (public, protected or private), abstract, static, final, synchronized, native.

WRONG

final public class Foo {
    public static final int attr1;
    static public int attr2;
}

RIGHT

public final class Foo {
    public static final int attr1;
    public static int attr2;
}

JAN_016: Put The main Method Last (High)

Tries to make the program comply with various coding standards regarding the form of class definitions.

WRONG

public class Foo {
    void bar1() {}

    public static void main(String args[]) {}

    void bar2() {}
}

RIGHT

public class Foo {
    void bar1() {}
    void bar2() {}

    public static void main(String args[]) {}
}

JAN_017: Put The public Class First (High)

According to Sun coding conventions, the public class or interface should be the first class or interface in the file.

WRONG

class Helper {
    // some code
}

public class Foo {
    // some code
}

RIGHT

public class Foo {
    // some code
}

class Helper {
    // some code
}

Appendix A - Conventions Rules

3. 2. J2EE Naming Conventions Rules