{"title":"Naming Conventions","description":"","content":"Every name you pick in a Java program tells the next reader something about what it is. The compiler is happy with almost any name that follows a few mechanical rules, but the Java community has settled on a set of conventions that everyone follows: PascalCase for classes, camelCase for methods and variables, UPPER_SNAKE_CASE for constants, and lowercase dotted names for packages. This lesson covers what's enforced by the compiler, what's enforced only by convention, and why those conventions are worth following from your very first program.\n\n---\n\n# What the Compiler Enforces\n\nBefore we get to convention, there are a few hard rules. An identifier in Java is any name you pick: a class, a method, a variable, a parameter, a field. The compiler enforces three rules on every identifier:\n\n- It must start with a letter, an underscore `_`, or a dollar sign `$`.\n- After the first character, it may contain letters, digits, underscores, and dollar signs.\n- It cannot be a Java reserved word like `int`, `class`, or `return`.\n\nIdentifiers are also case-sensitive. `customerName` and `CustomerName` are two different identifiers, and Java will treat them as completely unrelated names.\n\nA small program that shows what the compiler accepts:\n\n\n```java\npublic class IdentifierRules {\n public static void main(String[] args) {\n int itemCount = 3;\n int _backupCount = 5;\n int $promoCount = 1;\n int cart2 = itemCount + _backupCount + $promoCount;\n System.out.println(\"Total items: \" + cart2);\n }\n}\n```\n\n\nAll four variable names compile because each starts with a legal first character. The compiler doesn't care that `_backupCount` and `$promoCount` look unusual.\n\nTrying to start a name with a digit or use a reserved word fails immediately:\n\n\n```java\npublic class BadNames {\n public static void main(String[] args) {\n int 2ndItem = 5; // starts with a digit, compile error\n int class = 10; // 'class' is a reserved word, compile error\n }\n}\n```\n\n\nThe compiler reports `illegal start of expression` or `not a statement` for the first line and ` expected` for the second. Both errors mean \"that's not a legal name.\"\n\nFor reference, some of the reserved words you cannot use as identifiers:\n\n\n| Category | Words |\n| ----------- | --------------------------------------------------------------------------- |\n| Primitives | `boolean`, `byte`, `short`, `int`, `long`, `float`, `double`, `char` |\n| Control | `if`, `else`, `for`, `while`, `do`, `switch`, `case`, `break`, `continue`, `return` |\n| OOP | `class`, `interface`, `extends`, `implements`, `new`, `this`, `super`, `package`, `import` |\n| Modifiers | `public`, `private`, `protected`, `static`, `final`, `abstract` |\n| Exceptions | `try`, `catch`, `finally`, `throw`, `throws` |\n| Literals | `true`, `false`, `null` (not technically keywords but still reserved) |\n\n\nYou don't need to memorize the full list. Your IDE highlights reserved words in a different color, and the compiler will catch any slip-up before you can run the program.\n\n---\n\n# Classes and Interfaces: PascalCase\n\nClass and interface names use PascalCase: every word starts with a capital letter, including the first one, and there are no separators between words.\n\n\n```java\npublic class ShoppingCart {\n public static void main(String[] args) {\n ShoppingCart cart = new ShoppingCart();\n System.out.println(\"Created a new cart\");\n }\n}\n```\n\n\nOther examples that follow the convention: `Customer`, `Order`, `OrderStatus`, `ProductCatalog`, `PaymentMethod`. Each word is capitalized and there are no underscores.\n\nInterfaces follow the same rule. You'd write `Comparable`, `Iterable`, or `PaymentProcessor`, never `comparable` or `payment_processor`.\n\nThe reason PascalCase wins for types is readability. When you see `ShoppingCart cart = new ShoppingCart();`, the capital letters tell you at a glance which token is a type and which is a variable. If both were lowercase, the line would look like a soup of words and you'd have to think harder to parse it.\n\nA common mistake is naming classes like methods:\n\n\n```java\n// Compiles fine, but violates convention\npublic class shoppingCart {\n public static void main(String[] args) {\n System.out.println(\"This compiles, but no Java codebase looks like this\");\n }\n}\n```\n\n\nThe compiler doesn't complain. Every Java reviewer will. Stick with `ShoppingCart`.\n\n---\n\n# Methods and Variables: camelCase\n\nMethods and variables use camelCase: the first word is lowercase, every following word starts with a capital letter.\n\n\n```java\npublic class CartExample {\n public static void main(String[] args) {\n int itemCount = 5;\n double unitPrice = 19.99;\n double cartTotal = calculateTotal(itemCount, unitPrice);\n System.out.println(\"Cart total: $\" + cartTotal);\n }\n\n public static double calculateTotal(int quantity, double pricePerItem) {\n return quantity * pricePerItem;\n }\n}\n```\n\n\n`itemCount`, `unitPrice`, `cartTotal`, and `calculateTotal` all follow the same shape. Compare that with how the same code looks if you fight the convention:\n\n\n```java\n// Same code, broken naming\nint item_count = 5;\ndouble UnitPrice = 19.99;\ndouble CART_TOTAL = calculateTotal(item_count, UnitPrice);\n```\n\n\nThe compiler still accepts it. A reader scanning the file has to slow down and think \"is `CART_TOTAL` a constant? Is `UnitPrice` a class?\" Following the convention removes that friction.\n\nParameter names follow the same rule as local variables: camelCase, descriptive. `pricePerItem` is better than `p`, and `quantity` is better than `qty` unless your team has a strong reason for the abbreviation.\n\n---\n\n# Constants: UPPER_SNAKE_CASE\n\nConstants, declared as `static final`, use uppercase letters with underscores between words.\n\n\n```java\npublic class PricingRules {\n public static final double TAX_RATE = 0.08;\n public static final int MAX_CART_ITEMS = 50;\n public static final String DEFAULT_CURRENCY = \"USD\";\n\n public static void main(String[] args) {\n double subtotal = 100.00;\n double tax = subtotal * TAX_RATE;\n System.out.println(\"Tax on $\" + subtotal + \": $\" + tax);\n System.out.println(\"Cart limit: \" + MAX_CART_ITEMS + \" items\");\n }\n}\n```\n\n\n`TAX_RATE`, `MAX_CART_ITEMS`, and `DEFAULT_CURRENCY` are constants because they're declared `static final`: one value per class, never changes after assignment. The screaming uppercase tells the reader \"this number didn't come from user input, you can rely on it not changing.\"\n\nA non-constant should never use UPPER_SNAKE_CASE. Writing `int CART_TOTAL = 0;` inside `main` confuses everyone who reads it: they'll assume the value is fixed when it's a local variable.\n\n---\n\n# Packages: lowercase.with.dots\n\nPackages use all lowercase, with dots separating each segment. The convention is to start with a reverse domain name to avoid collisions.\n\n\n| Good | Bad | Reason |\n| -------------------------- | ------------------------- | ----------------------------------- |\n| `com.shop.inventory` | `Com.Shop.Inventory` | No uppercase in package names |\n| `com.shop.orders` | `com.shop.Orders` | No PascalCase in package names |\n| `io.algomaster.cart` | `io.algoMaster.cart` | No camelCase in package names |\n| `com.shop.user` | `com.shop.user_service` | Avoid underscores in package names |\n\n\nThe full layout typically looks like this:\n\n\n```mermaid\nflowchart TD\n A[Package
com.shop.inventory]:::cyan --> B[Class
ProductCatalog]:::orange\n B --> C[Method / Variable
findProduct, productList]:::green\n B --> D[Constant
MAX_RESULTS]:::red\n B --> E[Type Parameter
T, E, K, V]:::teal\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nEach level of the diagram uses a different case style, and that's intentional: when you read a fully qualified name like `com.shop.inventory.ProductCatalog.MAX_RESULTS`, the case tells you what each segment is. The dots separate packages, the capital letter marks the class, and the all-caps tail marks a constant.\n\nFor now, the takeaway is the casing rule: lowercase, dots, no camelCase, no underscores.\n\n---\n\n# Method Naming Idioms\n\nMethod names usually start with a verb because methods do things. A few idioms show up in almost every Java codebase:\n\n- **Getters and setters.** A property named `email` is read by `getEmail()` and written by `setEmail(String email)`. For boolean properties, the getter usually starts with `is`, `has`, or `can`: `isShipped()`, `hasDiscount()`, `canCancel()`. Frameworks like Spring and Jackson rely on this pattern, so following it is more than cosmetic.\n- **Boolean variables and method names.** Any boolean should read like a yes-or-no question. `isPaid`, `hasShipped`, `canCancel`, `shouldRefund`. Drop the name into a sentence like \"if `isPaid` then...\" and check that it sounds natural.\n- **Action methods.** Methods that perform actions start with verbs: `addItem`, `removeItem`, `checkout`, `placeOrder`, `applyDiscount`. Avoid noun-only names like `order` or `cart` for methods. If you can rewrite the name as \"do X to Y,\" it usually reads better.\n\nA small `Order` class that puts these idioms together:\n\n\n```java\npublic class Order {\n private String orderId;\n private boolean paid;\n private boolean shipped;\n\n public Order(String orderId) {\n this.orderId = orderId;\n this.paid = false;\n this.shipped = false;\n }\n\n public String getOrderId() {\n return orderId;\n }\n\n public boolean isPaid() {\n return paid;\n }\n\n public boolean isShipped() {\n return shipped;\n }\n\n public void markPaid() {\n this.paid = true;\n }\n\n public void shipOrder() {\n if (!paid) {\n System.out.println(\"Cannot ship unpaid order: \" + orderId);\n return;\n }\n this.shipped = true;\n }\n\n public static void main(String[] args) {\n Order order = new Order(\"ORD-1001\");\n order.markPaid();\n order.shipOrder();\n System.out.println(\"Order \" + order.getOrderId() + \" shipped: \" + order.isShipped());\n }\n}\n```\n\n\n`isPaid()` reads naturally inside the `if` check: `if (!paid)`. That's the test for whether your boolean name is good. If swapping it into a conditional sounds awkward, rename it.\n\n---\n\n# Acronyms in Names\n\nTreat acronyms as words in camelCase or PascalCase. Capitalize only the first letter, even when the acronym is two or three letters long.\n\n\n| Good | Bad |\n| ------------- | ------------- |\n| `HttpClient` | `HTTPClient` |\n| `XmlParser` | `XMLParser` |\n| `JsonReader` | `JSONReader` |\n| `userId` | `userID` |\n| `customerUrl` | `customerURL` |\n\n\nThe reason is consistency. When you have a class name like `HTTPSURLConnection`, the eye can't tell where one word ends and the next begins. `HttpsUrlConnection` reads cleanly. The standard library mostly follows this rule (`HttpURLConnection` is the famous holdout that everyone points to as an example of why this matters).\n\nFor variables, the same rule applies. `id`, `url`, and `xml` all become regular lowercase when they appear at the start of a name (`id`, `url`, `xmlBody`) and capitalize only the first letter in the middle of a name (`customerId`, `productUrl`, `responseXml`).\n\n---\n\n# Things to Avoid\n\nA few patterns show up in early code that Java reviewers flag.\n\n**Single-letter names for anything other than loop indices or generics.** Inside a loop, `i`, `j`, and `k` are fine for indices. Type parameters like `T`, `E`, `K`, and `V` are fine in generics. Anywhere else, a single letter hides what the variable is for. `double p = 19.99` is shorter than `double price = 19.99`, but the savings cost you every time you read the code.\n\n**Hungarian notation.** Writing `strName`, `iCount`, or `bIsPaid` adds the type to the name. Java already shows you the type in the declaration, so prefixing it again is noise. Use `name`, `count`, `isPaid` instead.\n\n**All-caps for non-constants.** UPPER_SNAKE_CASE is reserved for `static final` constants. Using it for local variables or parameters confuses every reader, because they'll trust the value not to change.\n\n**Names that shadow built-in types or classes.** Writing `String String = \"hello\"` compiles, but it shadows the type name inside that scope and makes the rest of the code hard to read. The same applies to `Integer`, `List`, `Map`. Pick a different name.\n\n**`$` prefix.** The compiler accepts `$promoCount` as a name, but the dollar sign is reserved by convention for tool-generated code (inner class names like `Outer$Inner` use it). Don't put `$` in your own identifiers.\n\n**Vague names.** `data`, `info`, `manager`, `tmp`, `helper`, `value`. These names tell the reader nothing about what's stored or what the method does. A variable called `data` could be anything. A class called `CartManager` could do anything. Prefer concrete names: `cartItems`, `customerProfile`, `pendingOrders`.\n\n---\n\n# Tests: A Note on Common Practice\n\nTest code follows its own conventions, and knowing the casing rules upfront helps test code read the same way as production code.\n\n- **Test classes** are usually named after the class they test, with a `Test` suffix: `ShoppingCartTest`, `OrderTest`, `CustomerRepositoryTest`.\n- **Test methods** often use a longer, descriptive form: `methodName_condition_expected`. For example, `applyDiscount_withExpiredCoupon_returnsOriginalPrice` or `checkout_emptyCart_throwsException`.\n\nThe underscores in test method names are a deliberate exception to the camelCase rule, because the names get long and the underscores make them easier to scan in a failure report. This is convention, not a compiler requirement.\n\n---\n\n# Bad Name vs Good Name\n\nA side-by-side summary of common naming mistakes and the conventional fix.\n\n\n| Category | Bad | Good | Why |\n| ---------- | ------------------------------ | -------------------------- | ----------------------------------------- |\n| Class | `shoppingcart` | `ShoppingCart` | Classes use PascalCase |\n| Class | `shopping_cart` | `ShoppingCart` | No underscores in class names |\n| Interface | `payment_processor` | `PaymentProcessor` | Interfaces use PascalCase |\n| Method | `CalculateTotal` | `calculateTotal` | Methods use camelCase |\n| Method | `total` | `calculateTotal` | Methods start with a verb |\n| Variable | `ItemCount` | `itemCount` | Variables use camelCase |\n| Variable | `i_count` | `itemCount` | No underscores or Hungarian prefix |\n| Variable | `p` | `productPrice` | Avoid single-letter names |\n| Boolean | `paid_flag` | `isPaid` | Booleans read as yes/no questions |\n| Boolean | `shipped` | `isShipped` or `hasShipped`| Prefix makes intent obvious |\n| Constant | `maxItems` | `MAX_ITEMS` | Constants use UPPER_SNAKE_CASE |\n| Constant | `TaxRate` | `TAX_RATE` | All caps, with underscores |\n| Package | `Com.Shop.Inventory` | `com.shop.inventory` | Packages are all lowercase |\n| Package | `com.shop.product_catalog` | `com.shop.productcatalog` | No underscores in package names |\n| Acronym | `HTTPClient` | `HttpClient` | Treat acronyms as words |\n| Acronym | `userID` | `userId` | Only capitalize the first letter |\n| Vague | `data`, `info`, `tmp` | `cartItems`, `customerInfo`, `tempTotal` | Names should describe content |\n\n\n---\n\n# A Cleaned-Up Example\n\nA small `Customer` example that pulls every convention together. The casing tells you what each name is without needing comments.\n\n\n```java\npackage com.shop.customers;\n\npublic class Customer {\n public static final int MAX_NAME_LENGTH = 100;\n public static final String DEFAULT_COUNTRY = \"USA\";\n\n private String customerId;\n private String fullName;\n private String email;\n private boolean emailVerified;\n\n public Customer(String customerId, String fullName, String email) {\n this.customerId = customerId;\n this.fullName = fullName;\n this.email = email;\n this.emailVerified = false;\n }\n\n public String getCustomerId() {\n return customerId;\n }\n\n public String getFullName() {\n return fullName;\n }\n\n public boolean isEmailVerified() {\n return emailVerified;\n }\n\n public void verifyEmail() {\n this.emailVerified = true;\n }\n\n public static void main(String[] args) {\n Customer customer = new Customer(\"CUST-42\", \"Alex Lee\", \"alex@example.com\");\n customer.verifyEmail();\n System.out.println(\"Customer: \" + customer.getFullName());\n System.out.println(\"Verified: \" + customer.isEmailVerified());\n System.out.println(\"Country default: \" + DEFAULT_COUNTRY);\n }\n}\n```\n\n\nThe package is lowercase. The class is PascalCase. The two constants are UPPER_SNAKE_CASE. The fields and methods use camelCase. The boolean is `emailVerified` and reads naturally inside `isEmailVerified()`. The getter and setter idioms match what frameworks expect. Every name is doing two jobs: describing the value and signaling its category by case.","pageType":"java"}

Naming Conventions

Get Premium