Java's naming conventions

Java's naming convention standards

Java's standard naming conventions to differentiate between classes, types, methods, packages and variables include the following:

1. Traditional PascalCase.
2. lowerCamelCase.
3. SCREAMING_SNAKE_CASE.
4. FLAMING-KEBAB-CASE.
5. Dot notation.

Here's how these various naming conventions differ from each other, along with examples of when to use them in your code.

Naming rules vs. standards and conventions

From the compiler's perspective, you can name your classes and variables practically whatever you want. The official syntax rules for naming a variable or method in Java are lax.

For variables, the first letter of a variable must be either a letter, dollar sign or an underscore. After that, any combination of valid Unicode characters or digits is allowed. It's not very restrictive.

However, rules are different from conventions. Java naming conventions for variables, methods and reference types are where things get a little more complicated.

For example, you can start a Java variable with a dollar sign or an underscore -- but nobody does that. Sometimes machine-generated code prepends a dollar sign or underscores a Java variable to emphasize the nonhuman origins, but that's about it.

PascalCase for Java reference types

There are five reference types in Java: classes, interfaces, annotations, enums and the recently added record. The standard Java naming convention demands that programmers write all reference types in Pascal case, also known as upper camel case.

Here are three examples of reference types defined within the JAX-RS API for building RESTful web services:

• QueryParam.
• ServerErrorException.
• RuntimeType.

Lower camel case for Java variables

For variables, the Java naming convention is to always start with a lowercase letter and then capitalize the first letter of every subsequent word. Variables in Java are not allowed to contain white space, so variables must be made from compound words.

The convention here is to use lower camel case. Here are three examples of variables that follow this naming convention:

• firstName.
• timeToFirstLoad.
• coffeeSize.

Naming Java methods

Lower camel case, also known as dromedary case, is also the Java naming convention for methods. Here are three examples of properly named Java methods from the String class:

• compareToIgnoreCase(String str)
• copyValueOf(char[] data)
• equalsIgnoreCase(String anotherString)

Screaming SnakeCase for constants

The only exception to the lowerCamelCase rule is for variables with a constant value. Any variable decorated with a static final keyword combination should be written in screaming snake case -- all letters are uppercase, and compound words are separated by an underscore.

Here are three examples of constants defined within the Spring Boot API, using screaming snake case:

• NESTED_PROPERTY_SEPARATOR.
• DEFAULT_TASK_EXECUTOR_BEAN_NAME.
• GLOBAL_SUFFIX.

Kebab case in Java

Kebab case refers to a naming convention in which each word in the variable's name is separated by a dash, similar to the snake case. However, there is no artifact in the Java programming language for which kebab case is recommended.

Mainly, the problem is that the dash in a kebab-cased variable can be easily confused with a minus sign, which can make reading and troubleshooting difficult. To steer clear of any confusion or controversy with Java naming conventions, having a dash in a variable, method or reference type in Java is not recommended.

Dot notation for package names

The convention for packages is different from the Java naming conventions used for variables, methods and reference types.

Packages are always written in lowercase letters, with a dot between words. A Java package is a reference to the file system; the dot in a package name maps to the set of folders and subfolders in which a given Java class or interface resides.

Here are three examples of packages that are part of a standard JDK installation:

• net.http.
• management.rmi.
• transaction.xa.

Cameron McKenzie has been a Java EE software engineer for 20 years. His current specialties include Agile development; DevOps; Spring; and container-based technologies such as Docker, Swarm and Kubernetes.