Naming Conventions

Naming conventions are the agreed-upon rules for choosing identifiers in Java — names for classes, variables, methods, packages, and constants. They are not enforced by the compiler, but following them makes your code immediately readable to any Java developer on the planet.

Note: The Java Language Specification does not mandate these conventions, but the Java Code Conventions document published by Sun/Oracle (and universally adopted by the community) does. Every major IDE and linter checks for them.

Why Naming Conventions Matter

When you open a well-named Java file, you instantly know what each identifier represents without reading a single comment. Poor naming forces readers to reverse-engineer intent. Consider:

// Bad: meaningless names
int x = 86400;
String s = "Alice";

// Good: self-documenting names
int secondsPerDay = 86400;
String customerName = "Alice";

Good names also reduce bugs — a variable called isLoggedIn (a boolean) is far less likely to be misused than one called flag.

Classes and Interfaces

Use UpperCamelCase (also called PascalCase): capitalise the first letter of every word, no underscores.

// Classes
public class BankAccount { }
public class HttpRequestHandler { }

// Interfaces
public interface Serializable { }
public interface PaymentGateway { }

• Choose a noun or noun phrase for classes (Customer, OrderProcessor).
• Choose an adjective or capability phrase for interfaces (Runnable, Comparable, Closeable).
• Avoid abbreviations unless the abbreviation is universally known (URL, HTML, HTTP are fine).

Methods

Use lowerCamelCase: start with a lowercase letter, capitalise each subsequent word.

public class Order {

    public double calculateTotal() {
        return 0.0;
    }

    public boolean isDiscountApplicable() {
        return false;
    }

    public void sendConfirmationEmail(String recipient) {
        // ...
    }
}

• Methods should be verbs or verb phrases: getBalance(), setName(), processPayment().
• Boolean-returning methods conventionally start with is, has, or can: isEmpty(), hasPermission(), canRetry().
• Getters and setters follow the JavaBeans pattern: getFieldName() / setFieldName(value).

Variables (Local and Instance)

Also lowerCamelCase. The name should describe the data it holds.

public class ShoppingCart {
    private int itemCount;           // instance variable
    private double totalPrice;       // instance variable

    public void addItem(String productName, double price) {
        // local variables
        double discountedPrice = price * 0.9;
        itemCount++;
        totalPrice += discountedPrice;
    }
}

Tip: Single-letter variables (i, j, k) are acceptable only inside short loop bodies where their scope is obvious. Everywhere else, be descriptive.

Avoid names that differ only by case — customer and Customer in the same scope is a recipe for confusion, even though Java allows it.

Constants

Constants (fields declared static final) use SCREAMING_SNAKE_CASE: all uppercase letters with words separated by underscores.

public class MathConstants {
    public static final double PI = 3.14159265358979;
    public static final int MAX_RETRY_COUNT = 3;
    public static final String DEFAULT_CHARSET = "UTF-8";
}

This visual distinction immediately tells a reader “this value never changes,” which is valuable context at a glance. See the final keyword page for more on static final fields.

Packages

Package names are always all lowercase, with words separated by dots. By convention, they start with a reversed domain name to guarantee global uniqueness.

// com.companyname.projectname.layer
package com.devcraftly.ecommerce.service;
package com.devcraftly.ecommerce.repository;
package org.apache.commons.lang3;

• Use only lowercase letters and digits — no underscores, no camelCase.
• Keep individual segments short and meaningful.
• If a segment would be a Java keyword (e.g., int), append an underscore: com.example.int_ (rare in practice).

Enums and Enum Constants

Enum type names follow UpperCamelCase (like classes). Enum constants follow SCREAMING_SNAKE_CASE (like constants).

public enum OrderStatus {
    PENDING,
    PROCESSING,
    SHIPPED,
    DELIVERED,
    CANCELLED
}

OrderStatus status = OrderStatus.SHIPPED;

You can learn more about enums on the Enums page.

Type Parameters (Generics)

Generic type parameters are single uppercase letters by convention.

Letter	Conventional meaning
T	Type (general purpose)
E	Element (collections)
K	Key (maps)
V	Value (maps)
N	Number
R	Return type (functions)

public class Box<T> {
    private T content;

    public void set(T content) { this.content = content; }
    public T get() { return content; }
}

For multiple type parameters, continue with single letters or short uppercase names: <K, V>, <T, R>.

Annotations

Annotation type names use UpperCamelCase, just like classes and interfaces.

@interface NotNull { }
@interface RequestMapping { }

Built-in examples: @Override, @Deprecated, @FunctionalInterface.

Quick Reference Table

Identifier type	Style	Example
Class	UpperCamelCase	CustomerOrder
Interface	UpperCamelCase	Printable
Method	lowerCamelCase	calculateTax()
Variable (local/instance)	lowerCamelCase	orderTotal
Constant (static final)	SCREAMING_SNAKE_CASE	MAX_SIZE
Package	all lowercase, dot-separated	com.example.util
Enum type	UpperCamelCase	DayOfWeek
Enum constant	SCREAMING_SNAKE_CASE	MONDAY
Generic type param	Single uppercase letter	T, E, K
Annotation	UpperCamelCase	NonNull

Common Mistakes to Avoid

// Using underscores in variable names (C-style) — avoid
int bank_balance = 1000;   // bad
int bankBalance = 1000;    // good

// Abbreviating aggressively — avoid
int usrCnt = 5;            // bad
int userCount = 5;         // good

// Starting a class name lowercase — avoid
class order { }            // bad
class Order { }            // good

// Using a reserved keyword — won't compile
// int class = 5;          // compile error
int classId = 5;           // good

See the Java Keywords page for the full list of reserved words you cannot use as identifiers.

Under the Hood

Naming conventions are entirely a source-level concern — the Java compiler (javac) converts names into bytecode references using the fully-qualified binary name (e.g., com/devcraftly/ecommerce/Order.class). The JVM loads classes by these binary names (see Class Loaders), so at runtime the human-readable names you chose exist only in the .class file’s constant pool as UTF-8 strings.

However, at the reflection level (see Reflection API), naming becomes critical again: Class.forName("com.devcraftly.ecommerce.Order") must match exactly the binary name stored in the bytecode. Tools like IDEs, debuggers, profilers, and javap all surface these stored names, so a well-named codebase is easier to navigate even in production diagnostics.

Java’s own standard library is a masterclass in these conventions — studying how java.util.ArrayList or java.util.concurrent.ConcurrentHashMap are named reveals why consistency at scale pays off.

Related Topics

• Classes & Objects — put naming conventions into practice as you define your first classes
• Methods — method naming and signature design in depth
• Java Keywords — the reserved words you cannot use as identifiers
• Enums — enum type and constant naming illustrated with real examples
• Access Modifiers — visibility rules that go hand-in-hand with well-named members
• Clean Code in Java — broader coding style principles that build on naming conventions