# Oracle Official Code Standard

Oracle official style guide (opens new window) for the Java Programming Language is a standard followed by developers at Oracle and recommended to be followed by any other Java developer. It covers filenames, file organization, indentation, comments, declarations, statements, white space, naming conventions, programming practices and includes a code example.

# Naming Conventions

# Package names

Package names should be all lower case without underscores or other special characters.
Package names begin with the reversed authority part of the web address of the company of the developer. This part can be followed a by project/program structure dependent package substructure.
Don’t use plural form. Follow the convention of the standard API which uses for instance java.lang.annotation and not java.lang.annotations.
Examples: com.yourcompany.widget.button, com.yourcompany.core.api

# Class, Interface and Enum Names

Class and enum names should typically be nouns.
Interface names should typically be nouns or adjectives ending with …able.
Use mixed case with the first letter in each word in upper case (i.e. CamelCase (opens new window)).
Match the regular expression ^[A-Z][a-zA-Z0-9]*$.
Use whole words and avoid using abbreviations unless the abbreviation is more widely used than the long form.
Format an abbreviation as a word if the it is part of a longer class name.
Examples: ArrayList, BigInteger, ArrayIndexOutOfBoundsException, Iterable.

# Method Names

Method names should typically be verbs or other descriptions of actions

They should match the regular expression ^[a-z][a-zA-Z0-9]*$.
Use mixed case with the first letter in lower case.
Examples: toString, hashCode

# Variables

Variable names should be in mixed case with the first letter in lower case

Match the regular expression ^[a-z][a-zA-Z0-9]*$
Further recommendation: Variables (opens new window)
Examples: elements, currentIndex

# Type Variables

For simple cases where there are few type variables involved use a single upper case letter.

Match the regular expression ^[A-Z][0-9]?$
If one letter is more descriptive than another (such as K and V for keys and values in maps or R for a function return type) use that, otherwise use T.
For complex cases where single letter type variables become confusing, use longer names written in all capital letters and use underscore (_) to separate words.
Examples: T, V, SRC_VERTEX

# Constants

Constants (static final fields whose content is immutable, by language rules or by convention) should be named with all capital letters and underscore (_) to separate words.

Match the regular expression ^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$
Examples: BUFFER_SIZE, MAX_LEVEL

# Other guidelines on naming

Avoid hiding/shadowing methods, variables and type variables in outer scopes.
Let the verbosity of the name correlate to the size of the scope. (For instance, use descriptive names for fields of large classes and brief names for local short-lived variables.)
When naming public static members, let the identifier be self descriptive if you believe they will be statically imported.
Further reading: Naming Section (opens new window) (in the official Java Style Guide)

_{Source: Java Style Guidelines (opens new window) from Oracle}

# Class Structure

# Order of class members

Class members should be ordered as follows:

Fields (in order of public, protected and private)
Constructors
Factory methods
Other Methods (in order of public, protected and private)

Ordering fields and methods primarily by their access modifiers or identifier is not required.

Here is an example of this order:

class Example {

    private int i;

    Example(int i) {
        this.i = i;
    }

    static Example getExample(int i) {
        return new Example(i);
    }

    @Override
    public String toString() {
        return "An example [" + i + "]";
    }

}

# Grouping of class members

Related fields should be grouped together.
A nested type may be declared right before its first use; otherwise it should be declared before the fields.
Constructors and overloaded methods should be grouped together by functionality and ordered with increasing arity. This implies that delegation among these constructs flow downward in the code.
Constructors should be grouped together without other members between.
Overloaded variants of a method should be grouped together without other members between.

# Annotations

Declaration annotations should be put on a separate line from the declaration being annotated.

@SuppressWarnings("unchecked")
public T[] toArray(T[] typeHolder) {
    ...
}

However, few or short annotations annotating a single-line method may be put on the same line as the method if it improves readability. For example, one may write:

@Nullable String getName() { return name; }

For a matter of consistency and readability, either all annotations should be put on the same line or each annotation should be put on a separate line.

// Bad.
@Deprecated @SafeVarargs
@CustomAnnotation
public final Tuple<T> extend(T... elements) {
    ...
}

// Even worse.
@Deprecated @SafeVarargs
@CustomAnnotation public final Tuple<T> extend(T... elements) {
    ...
}

// Good.
@Deprecated
@SafeVarargs
@CustomAnnotation
public final Tuple<T> extend(T... elements) {
    ...
}

// Good.
@Deprecated @SafeVarargs @CustomAnnotation
public final Tuple<T> extend(T... elements) {
    ...
}

# Import statements

// First java/javax packages
import java.util.ArrayList;
import javax.tools.JavaCompiler;

// Then third party libraries
import com.fasterxml.jackson.annotation.JsonProperty;

// Then project imports
import com.example.my.package.ClassA;
import com.example.my.package.ClassB;

// Then static imports (in the same order as above)
import static java.util.stream.Collectors.toList;

Import statements should be sorted…

…secondarily by package origin according to the following order
- Opening braces should be put on the end of the current line rather than on a line by its own.
- There should be a new line in front of a closing brace unless the block is empty (see Short Forms below)
- Braces are recommended even where the language makes them optional, such as single-line if and loop bodies.
  - Modifiers should go in the following order
    - All lines must be terminated with a line feed character (LF, ASCII value 10) and not for instance CR or CR+LF.
    - There may be no trailing white space at the end of a line.
    - The name of a source file must equal the name of the class it contains followed by the `.java` extension, even for files that only contain a package private class. This does not apply to files that do not contain any class declarations, such as `package-info.java`.
    - Source code and comments should generally not exceed 80 characters per line and rarely if ever exceed 100 characters per line, including indentation. The character limit must be judged on a case by case basis. What really matters is the semantical “density” and readability of the line. Making lines gratuitously long makes them hard to read; similarly, making “heroic attempts” to fit them into 80 columns can also make them hard to read. The flexibility outlined here aims to enable developers to avoid these extremes, not to maximize use of monitor real-estate.
    - URLs or example commands should not be wrapped.
    - Wrapping at a higher syntactical level is preferred over wrapping at a lower syntactical level.
    - There should be at most 1 statement per line.
    - A continuation line should be indented in one of the following four ways
      - A single blank line should be used to separate…
        - Package declaration - Class declarations - Constructors - Methods - Static initializers - Instance initializers
        …and may be used to separate logical groups of
        
        import statements
        
        fields
        
        statements
        
        Multiple consecutive blank lines should only be used to separate groups of related members and not as the standard inter-member spacing.
        
        # Horizontal Whitespace
        
        A single space should be used…
        - To separate keywords from neighboring opening or closing brackets and braces - Before and after all binary operators and operator like symbols such as arrows in lambda expressions and the colon in enhanced for loops (but not before the colon of a label) - After `//` that starts a comment. - After commas separating arguments and semicolons separating the parts of a for loop. - After the closing parenthesis of a cast.
        In variable declarations it is not recommended to align types and variables.
        
        # Special Characters
        
        Apart from LF the only allowed white space character is Space (ASCII value 32). Note that this implies that other white space characters (in, for instance, string and character literals) must be written in escaped form.
        
        `\'`, `\"`, `\\`, `\t`, `\b`, `\r`, `\f`, and `\n` should be preferred over corresponding octal (e.g. `\047`) or Unicode (e.g. `\u0027`) escaped characters.
        
        Should there be a need to go against the above rules for the sake of testing, the test should **generate** the required input programatically.
        
        # Variable Declarations
        
        One variable per declaration (and at most one declaration per line)
        
        Square brackets of arrays should be at the type (String[] args) and not on the variable (String args[]).
        
        Declare a local variable right before it is first used, and initialize it as close to the declaration as possible.
        
        # Remarks
        
        The examples above strictly follow the new [official style guide](http://cr.openjdk.java.net/%7Ealundblad/styleguide) from Oracle. They are in other words **not** subjectively made up by the authors of this page.
        
        The official style guide has been carefully written to be backward compatible with the [original style guide](http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html) and the majority of code out in the wild.
        
        The official style guide has been [peer](http://mail.openjdk.java.net/pipermail/discuss/2015-August/003766.html) [reviewed](http://mail.openjdk.java.net/pipermail/discuss/2015-August/003771.html) by among others, Brian Goetz (Java Language Architect) and Mark Reinhold (Chief Architect of the Java Platform).
        
        The examples are non-normative; While they intend to illustrate correct way of formatting the code, there may be other ways to correctly format the code. This is a general principle: There may be several ways to format the code, all adhering to the official guidelines.

← log4j / log4j2 Character encoding →

# Oracle Official Code Standard

# Naming Conventions

# Package names

# Class, Interface and Enum Names

# Method Names

# Variables

# Type Variables

# Constants

# Other guidelines on naming

# Class Structure

# Order of class members

# Grouping of class members

# Annotations

# Import statements

# Wildcard imports

# Redundant Parentheses

# Braces

# Short forms

# Modifiers

# Indentation

# Literals

# Package declaration

# Lambda Expressions

# Java Source Files

# Wrapping statements

# Wrapping Method Declarations

# Wrapping Expressions

# Whitespace

# Vertical Whitespace

# Horizontal Whitespace

# Special Characters

# Variable Declarations

# Remarks