Java Naming Best Practices

Names are the cheapest documentation you will ever write and the most expensive to get wrong. Java has a strong, near-universal set of naming conventions — codified in the original Java Language Specification and reinforced by the JDK, every major library, and tools like Checkstyle. Following them is not about taste: it lets any Java reader infer what a thing is from how it is written, before reading a single line of its body. This chapter collects the rules that matter and shows them at work.

The case conventions at a glance

Java assigns a distinct casing style to each kind of identifier. The casing alone tells the reader the category:

package com.w3docs.billing;          // lowercase, reverse-domain

public class InvoiceService {        // PascalCase class
  private static final int MAX_RETRY_COUNT = 3;  // UPPER_SNAKE_CASE constant
  private final TaxTable taxTable;   // camelCase field

  public BigDecimal calculateTotal(List<LineItem> lineItems) { ... } // camelCase method
}

Packages: lowercase and reverse-domain

Package names are always lowercase, with no underscores, and start from a domain you control reversed — com.w3docs.billing, not Billing or w3docs_billing. The reverse-domain prefix keeps your packages globally unique so they never collide with a third-party library on the classpath. Avoid Java keywords and digits as the first character of any segment.

package com.w3docs.billing.tax;   // good: lowercase, reverse-domain, dotted
// package Com.W3docs.Billing;    // bad: uppercase segments
// package com.w3docs.2024billing;// bad: segment starts with a digit

Classes are nouns, methods are verbs

A class, interface, enum, or record models a thing, so its name is a noun phrase in PascalCase: Order, PaymentGateway, OrderLine. A method does something, so its name is a verb phrase in camelCase: calculateTotal, sendInvoice, parseDate. Two strong sub-conventions follow:

• Methods that return a boolean read as a question: isEmpty, hasNext, canRetry.
• Classic accessors use the get/set prefix (getName, setName) — but Java records generate accessors named after the field with no prefix (name(), not getName()).

interface PaymentGateway {          // noun, PascalCase
  boolean isAvailable();            // boolean → question form
  Receipt charge(Money amount);     // verb phrase
}

record Customer(String name, String email) { }  // accessors: name(), email()

Constants, variables, and type parameters

A static final constant whose value is fixed at compile time uses UPPER_SNAKE_CASE so it stands out from ordinary variables: MAX_RETRY_COUNT, DEFAULT_TAX_RATE. Local variables, parameters, and fields are camelCase nouns that describe the value, not its type — prefer taxRate over d or theDouble. Generic type parameters are single uppercase letters by long-standing convention:

static final double DEFAULT_TAX_RATE = 0.20;        // constant
public <K, V> Map<K, V> copyOf(Map<K, V> source) { ... } // type params K, V

Avoid these common mistakes

A few anti-patterns show up again and again. They compile, but they fight the reader:

• Hungarian / type-encoded names — strName, iCount, lstOrders. The type is already in the declaration; the name should describe meaning.
• Single-letter locals beyond loop counters — c, x, tmp for a domain value hide intent.
• Cryptic abbreviations — calcGrsTtl. Spell words out; modern IDEs autocomplete.
• l (lowercase L) and O as variable names — they are visually indistinguishable from 1 and 0.
• Class names that are verbs (ProcessData) or method names that are nouns — prefer order.calculateTotal() for something that computes, reserving the bare noun form for pure accessors.

A worked example: the conventions in one program

This program puts every rule above into a single file — a constant, a record with no-prefix accessors, a boolean query method, a camelCase method with descriptive parameters, and a generic list. Read the source and the output together to see how the casing maps to the category.

What to take from the run:

• The two UPPER_SNAKE_CASE constants print as max retry count : 3 and default tax rate: 0.2 — their casing signals at the use site that these are fixed, shared values, not locals you can reassign.
• OrderLine is a PascalCase record, and the loop reads its data through productName(), quantity(), and lineTotal() — note there is no get prefix, because record accessors are named exactly after the component.
• isBulk() prints bulk=true for the 12-unit line and bulk=false for the 1-unit line: the is prefix told you it returned a boolean before you read its body, and the output confirms the convention pays off at the call site.
• calculateGrossTotal is a verb-phrase method whose parameters orderLines and taxRate describe meaning, not type — the result gross total : 111.60 (93.00 net times 1.20) is exactly what the method name promised.
• The final line uses List<String>, a generic parameterized with a concrete type, echoing the type-parameter convention (E for element) the JDK collections are declared with — the program prints [alpha, beta] to show the typed list in action.

Practice