What are the standard Java naming conventions for identifiers, and how do conventions differ from the compiler's rules?

## Rules vs conventions — the core distinction There are two completely different things often confused here: - **Rules** are enforced by the **compiler**. Break a rule (start a name with a digit, use a keyword) and your code **won't compile**. - **Conventions** are **agreed style**, not enforced by the compiler. Break a convention (name a class `customerorder` instead of `CustomerOrder`) and it **still compiles** — but other developers, linters, and code reviewers will object because it harms readability. Understanding which is which is itself an interview signal: many candidates wrongly believe casing conventions are enforced. ## The standard conventions Java has a long-established, near-universal set of conventions: - **Classes and interfaces:** `UpperCamelCase` (also called PascalCase) — every word capitalized, no separators: `Customer`, `CustomerOrder`, `HttpClient`. Interfaces are named the same way (no `I` prefix in Java, unlike C#). - **Methods and variables (fields, locals, parameters):** `lowerCamelCase` — first word lowercase, later words capitalized: `totalPrice`, `getUserName`, `index`. Methods are usually verbs/verb phrases; variables are nouns. - **Constants** (`static final` fields whose value never changes): `UPPER_SNAKE_CASE` — all caps with underscores between words: `MAX_SIZE`, `DEFAULT_TIMEOUT_MS`. - **Packages:** all **lowercase**, no underscores, typically a **reversed internet domain** to ensure global uniqueness: `com.example.billing`. Lowercase avoids clashes with class names on case-insensitive file systems. - **Type parameters** (generics): single uppercase letters by convention — `T` (type), `E` (element), `K`/`V` (key/value), `R` (result). - **Enum constants:** usually `UPPER_SNAKE_CASE` like constants (`Status.IN_PROGRESS`). ## The `$` and `_` conventions Both `$` and `_` are *legal* characters, but convention treats them specially: - **`$`** should be avoided in hand-written names. It is effectively reserved for **machine-generated / synthetic** identifiers — for example the compiler uses `$` in the names of nested and anonymous classes (`Outer$Inner`, `Outer$1`). Using `$` yourself risks clashing with generated names and reads as 'this was generated.' - **`_`** is fine *inside* names (`MAX_SIZE`) but a leading or trailing lone underscore on a normal variable is discouraged style, and a *bare* `_` is now reserved by the language entirely (it marks an unnamed binding). ## Why conventions matter even though they aren't enforced Consistent naming lets a reader infer a name's **role** instantly: `CustomerOrder` is a type, `customerOrder` is an instance/variable, `CUSTOMER_LIMIT` is a constant, `com.shop.orders` is a package. This shared vocabulary reduces cognitive load, makes code searchable, and is so standardized that tools (IDEs, linters like Checkstyle, code generators) assume it. Teams typically enforce conventions with a linter even though the compiler does not. ## Choosing good names (beyond casing) Conventions also include *quality* guidance: prefer descriptive, pronounceable names; avoid single letters except for short-lived loop counters (`i`, `j`) and generics; don't encode types into names (Hungarian notation is discouraged in Java); booleans often read as questions (`isReady`, `hasNext`). These aren't compiler rules either, but they're part of idiomatic Java. ## Summary The compiler only checks legality; conventions add a shared style layer: UpperCamelCase types, lowerCamelCase methods/variables, UPPER_SNAKE_CASE constants, lowercase packages, single-letter generics, and avoid `$`/leading `_` in hand-written names. Following them is about readability and team consistency, not compilation.