> For the complete documentation index, see [llms.txt](https://www.pranaypourkar.co.in/the-programmers-guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.pranaypourkar.co.in/the-programmers-guide/java/code-style-guidelines/naming-convention.md).
# Naming Convention
## About
Naming conventions are a fundamental part of code style that define how developers name variables, classes, methods, packages, constants, and other identifiers in a program. These conventions are not enforced by the compiler, but when followed consistently, they make code easier to read, maintain, and collaborate on.
Consistent naming conveys meaning, intent, and structure — and helps developers understand what the code is doing without needing extensive documentation. A good naming convention makes it easier to onboard new team members, reduce bugs, improve code reviews, and communicate intent across teams.
In Java, naming conventions are well-established and supported by most IDEs and tools. Adhering to these conventions signals professionalism, enhances productivity, and ensures better compatibility with third-party libraries and frameworks.
## Java Naming Conventions
### 1. **Package Names**
* Use all **lowercase** letters.
* Use your organization’s **reverse domain name** as the root.
* Avoid underscores and camelCase.
* Use meaningful package names representing features, not technical details.
{% hint style="success" %}
{% endhint %}
**Example:**
```java
// Good
com.example.billing.invoice
org.companyname.product.module.submodule
com.uber.payment.gateway
org.example.hr.attendance
// Bad
com.Example.HRModule
com.uber_Payment
```
### 2. **Class and Interface Names**
* Use **PascalCase** (a.k.a. UpperCamelCase).
* Should be **nouns** representing entities or concepts.
* Interfaces typically describe a capability (e.g., `Readable`, `Sortable`).
* Avoid using prefixes like `I` (e.g., `IUserService`) — unnecessary in Java.
{% hint style="success" %}
**Character Length Guidelines**
Ideally between **3 to 30 characters**.
* Too short names (e.g., `Usr`, `Mgr`) can be cryptic.
* Too long names (>30) become unwieldy, e.g., `CustomerAccountManagementServiceImpl`.
* Use meaningful compound words with camel case to keep clarity.
{% endhint %}
**Example:**
```java
// Good
public class UserAccount { ... }
public interface PaymentGateway { ... }
public class OrderProcessor { }
public interface Auditable { }
// Bad
public class orderprocessor { } // Starts with lowercase
public interface IAuditable { } // 'I' prefix is not Java idiomatic
```
### 3. **Enum Names and Constants**
* Enum type: **PascalCase**
* Enum constants: **ALL\_UPPERCASE** with underscores between words.
**Example:**
```java
public enum OrderStatus {
PENDING,
APPROVED,
REJECTED
}
```
### 4. **Method Names**
* Use **camelCase**.
* Should be **verbs** or verb phrases that clearly state the method’s action.
* Prefer clarity over brevity.
* Should describe the result or behavior, not the implementation.
{% hint style="success" %}
**Character Length Guidelines**
Typically **3 to 40 characters**.
* Should express the action clearly.
* Keep names concise but descriptive enough to avoid guessing.
* Examples:
* Good: `calculateInterestRate()`, `isUserAuthorized()`
* Too long: `calculateAnnualPercentageRateBasedOnUserCreditScore()`
{% endhint %}
**Examples:**
// Good
public void processPayment() { ... }
public String getCustomerEmail() { ... }
public void updateCustomerAddress() { }
public boolean hasActiveSubscription() { }
// Bad
public void doThing(); // unclear
public void doIt(); // Unclear intent
### 5. **Variable Names**
* Use **camelCase**.
* Should be **short but descriptive**.
* Avoid non-standard abbreviations and single letters (except loop counters).
* Should reflect the **purpose or contents**.
{% hint style="success" %}
**Character Length Guidelines**
Between **1 to 20 characters**, depending on scope.
* Short variables (like `i`, `j`, `k`) acceptable in small loops or anonymous usage.
* Otherwise, use descriptive names like `customerEmail`, `retryCount`.
* Avoid excessively long names that reduce code readability.
{% endhint %}
**Examples:**
```java
// Good
int totalItems;
String customerName;
List unpaidOrders;
String customerName;
int retryCount;
List pendingOrders;
// Bad
int t; // unclear
String nm; // abbreviated
```
### 6. **Boolean Variables**
* Prefix with **is**, **has**, **can**, or **should** to convey truthy meaning.
**Examples:**
```java
// Good
boolean isActive;
boolean hasPermission;
boolean canRetry;
boolean shouldRetry;
boolean isVerified;
boolean hasUnpaidInvoices;
// Bad
boolean retryFlag; // unclear intent
boolean verifiedStatus; // Less clear when used in conditions
```
### 7. **Constants**
* Use **ALL\_UPPERCASE** with underscores.
* Should be `public static final`.
* Names should be meaningful and reflect fixed values.
**Examples:**
```java
public static final int MAX_RETRY_ATTEMPTS = 3;
public static final String DEFAULT_CURRENCY = "USD";
```
### 8. **Generic Type Parameters**
* Single uppercase letters by convention:
* `T` – Type
* `E` – Element
* `K`, `V` – Key, Value (for Maps)
* `R` – Return type
For better readability in domain-specific contexts, descriptive names like `Payload`, `Response`, or `Request` can be used.
**Examples:**
```java
public interface Repository { ... }
public class ApiResponse { ... }
```
### **9. Test Method Naming**
* Should describe **what is being tested** and **under what condition**.
* Use **camelCase** or `snake_case` for readability.
* Avoid vague names like `test1()` or `testMethod()`.
**Examples:**
```java
shouldThrowExceptionWhenAmountIsNegative()
calculateTax_shouldReturnZeroForEmptyOrder()
```
### 10. **Layer-Specific Naming Conventions (Optional but Helpful)**
Adopting a **suffix-based naming strategy** for layered components enhances clarity:
| Layer | Naming Pattern | Example |
|---|
| Controller | Ends with Controller | CustomerController |
| Service | Ends with Service | NotificationService |
| Repository/DAO | Ends with Repository | OrderRepository, UserDAO |
| DTO | Ends with Dto or Request/Response | UserRequestDto, OrderResponse |
| Entity | Ends with Entity | InvoiceEntity |
## General Guidelines
### 1. Avoiding Abbreviations and Acronyms
* Avoid abbreviations unless:
* They are widely recognized (e.g., `URL`, `HTTP`, `ID`).
* They enhance clarity without causing confusion.
* When using acronyms, follow casing rules:
* Acronyms in class names: capitalize first letter only: `XmlParser` (not `XMLParser`)
* Acronyms in constants: all uppercase `MAX_URL_LENGTH`
* Examples:
* Good: `userId`, `httpRequest`
* Bad: `usrId`, `htpReq`
### 2. Reserved Keywords and Avoiding Collisions
* Never use Java reserved keywords as identifiers (`class`, `int`, `package`, etc.).
* Avoid names that collide with standard library classes (e.g., naming a class `String` or `List`).
### 3. Naming and Readability Trade-offs
* Avoid **overly descriptive names** that break readability:
```java
// Too verbose and hard to read:
int numberOfTimesUserHasAttemptedLoginFailureAndWasBlocked;
// Better:
int loginFailureCount;
```
* Balance descriptiveness with brevity.
### 4. Maximum Identifier Length in Java
* Java language specification does not enforce strict max length for identifiers.
* However, JVM implementations or tools may have limits (usually large, e.g., 65535 bytes).
* In practice, keep identifiers **under 255 characters** for compatibility and tooling ease.
### 5. Unicode and Non-ASCII Characters
* Java supports Unicode in identifiers.
* **Avoid** using non-ASCII characters for identifiers, even if allowed, to ensure:
* Code portability
* Ease of typing and sharing
* Compatibility with various tools and editors
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://www.pranaypourkar.co.in/the-programmers-guide/java/code-style-guidelines/naming-convention.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.