Method Naming Conventions — Method Signature Design | OneNoughtOne

0/86

System Design (LLD)Method Signature Design

Method Signature Design

LevelIntermediate

Duration60 mins

TopicMethod Signature Design

1 / 4

Method Naming Conventions

The Name Is the Interface

Before a single line of documentation is read, before parameter types are examined, before return values are considered—a method name is encountered. That name is not merely an identifier; it is a promise . It declares intent. It sets expectations. It either guides understanding or sows confusion. In the world of API design, method naming is not a trivial detail relegated to style guides and linting rules. It is the first act of communication between the API designer and every developer who will ever use that API. A well-named method reveals its purpose instantly. A poorly-named method creates friction that compounds across every invocation, every code review, every debugging session. Consider the difference between process() and validateAndSubmitOrder() . The former tells you almost nothing; the latter tells you almost everything. That distinction—multiplied across hundreds of methods in a codebase—is the difference between APIs that developers love and APIs that developers dread.

What You Will Master

By the end of this page, you will understand the foundational principles of method naming, recognize common anti-patterns, and apply proven naming strategies that make APIs self-documenting and intuitive. You'll think about naming the way Principal Engineers do—as a design decision with lasting consequences.

Why Method Names Matter

Method names are not merely labels—they are the primary mechanism for conveying design intent . When developers encounter your API, names are what they see first in autocomplete, what they search for, what they discuss in code reviews, and what they remember. The cognitive load imposed by poor naming accumulates across every interaction with your API. The Cost of Poor Naming Poor method names create a cascade of problems: Increased learning curve — Developers must read documentation for every method instead of inferring purpose from names. Higher defect rates — When names don't reflect behavior, developers make incorrect assumptions, leading to bugs. Reduced discoverability — In autocomplete scenarios, vague names don't surface when developers search for functionality. Code review friction — Reviewers must constantly verify that method names match their implementations. Maintenance burden — Future maintainers inherit confusion, often perpetuating or worsening naming inconsistencies.

Impact of Naming Quality Across the Development Lifecycle
Development Phase	Good Naming Impact	Poor Naming Impact
Discovery/Learning	Self-documenting, intuitive exploration	Requires documentation for every method
Implementation	Code reads like natural language	Constant back-and-forth with docs
Code Review	Intent is immediately apparent	Reviewers question every method call
Debugging	Call stacks reveal behavior flow	Method names obscure execution path
Maintenance	Changes are confidently localized	Fear of unintended side effects
Onboarding	New developers ramp up quickly	Tribal knowledge required to understand

The Naming Debt Compound Effect

Poor naming is a form of technical debt that compounds silently. Unlike performance issues that manifest as measurable slowdowns, naming debt manifests as slower development, more bugs, and developer frustration—all of which are harder to quantify but no less real.

Foundational Naming Principles

Effective method naming rests on several foundational principles that transcend specific programming languages or frameworks. These principles should guide every naming decision you make.

Core Naming Principles

•Reveal Intent, Not Implementation — A method name should describe what the method does, not how it does it. sendEmail() is better than useSmtpToTransmit(). Implementation may change; intent should remain stable.
•Be Precise, Not Vague — Avoid generic names like handle(), process(), manage(), or execute(). These words carry almost no semantic meaning. Prefer processPayment(), handleAuthenticationFailure(), or executeScheduledJob().
•Use Domain Vocabulary — Names should come from the problem domain, not technical jargon. If the business calls it an 'Order', don't call it a 'Transaction'. Ubiquitous language from Domain-Driven Design applies here.
•Maintain Consistent Conventions — If you use get for retrieval in one place, don't use fetch, retrieve, or obtain elsewhere. Consistency reduces cognitive load dramatically.
•Optimize for Readability, Not Brevity — A longer, clearer name is almost always better than a shorter, ambiguous one. calculateMonthlyInterestPayment() beats calcMIP().
•Consider the Call Site — Methods are read at call sites far more often than at definition sites. order.cancel() reads better than order.setCancelled(true).

The Grain of Truth in Brevity While we advocate for clarity over brevity, there's a legitimate concern about overly long names. The key is to achieve maximum clarity per character . Each word in a method name should add meaning. Remove words that don't contribute. For example, getUserFromDatabaseById() can be simplified to getUser() if the 'from database' part is implied by the class context and 'by ID' is implied by the parameter type. Context already communicates some information; don't repeat it in the name.

The Newspaper Test

Read your method call in the context of surrounding code. Does it read like a sentence in a newspaper article? Good names allow code to be read almost like prose: if (user.canAccessResource(document)) { audit.logAccessGranted(user, document); }

Verb-First Naming Patterns

In most programming languages, methods represent actions —things an object can do. Actions are naturally described with verbs. Therefore, the predominant convention is to start method names with a verb that describes the action being performed. Standard Verb Prefixes and Their Meanings Over decades of software development, certain verb prefixes have acquired standardized meanings. Deviating from these meanings creates confusion; adhering to them leverages developers' existing mental models.

Common Verb Prefixes and Their Semantic Contracts
Prefix	Semantic Meaning	Expectations	Example
`get`	Retrieve a value	No side effects, returns non-null or throws	`getUser(id)`
`find`	Search for a value	No side effects, may return null	`findUserByEmail(email)`
`set`	Assign a value	Mutates state, usually returns void	`setPassword(newPassword)`
`is/has/can`	Query boolean state	No side effects, returns boolean	`isActive()`, `hasPermission()`
`create`	Construct a new entity	Returns new object, may persist	`createOrder(items)`
`delete/remove`	Eliminate an entity	Mutates state, idempotent preferred	`deleteUser(id)`
`update`	Modify existing entity	Mutates state, typically partial	`updateProfile(changes)`
`compute/calculate`	Derive a value from inputs	Pure function, deterministic	`calculateTax(order)`
`validate`	Check correctness	No mutation, returns boolean or throws	`validateEmail(email)`
`parse`	Transform string to type	Pure function, may throw on bad input	`parseDate(dateString)`
`format`	Transform type to string	Pure function, deterministic	`formatCurrency(amount)`
`ensure/require`	Guarantee a condition	Throws if condition not met	`ensureAuthenticated()`
`try`	Attempt operation	Returns success/failure, doesn't throw	`tryParse(input)`
`initialize/init`	Set up object state	Called once, usually in lifecycle	`initialize(config)`
`dispose/close`	Release resources	Called for cleanup, idempotent	`dispose()`, `close()`

Semantic Precision Matters Notice the subtle but important distinction between get and find . A get method implies the entity is expected to exist; if it doesn't, an exception is thrown. A find method implies the entity may or may not exist; null (or Optional/Maybe) is a valid return value. This isn't arbitrary—it communicates intent at the call site : // Developer knows this will throw if user doesn't exist const user = userRepository.getUser(id); // Developer knows they need to handle the null case const user = userRepository.findUserByEmail(email); if (user === null) { // Handle missing user } When these semantic contracts are violated—e.g., a get method that returns null—developers write incorrect code based on correct assumptions about API conventions.

Language-Specific Conventions

Some languages have established variations. In Python, properties often use @property decorators instead of get_prefixes. In Ruby, boolean methods end with ? . In Kotlin, property access syntax is preferred. Always respect language-specific idioms while maintaining semantic clarity.

Naming Patterns for Different Method Types

Different categories of methods have evolved distinct naming patterns. Understanding these patterns helps maintain consistency and set correct expectations.

Accessor Methods (Getters) Accessors retrieve internal state without modification. They should: Start with get (or language-appropriate equivalent) Return a value (never void) Be side-effect free Be idempotent (same result on repeated calls, assuming no external mutation) // Good accessors String getName() int getAge() List<Order> getOrders() Optional<Address> getShippingAddress() // Boolean accessors use is/has/can boolean isActive() boolean hasOrders() boolean canEdit() Mutator Methods (Setters) Mutators modify internal state. They should: Start with set for simple property assignment Use more specific verbs for complex mutations Consider returning this for fluent APIs Consider returning the previous value if useful // Simple setters void setName(String name) void setAge(int age) // Fluent setters (return this) User setName(String name) Builder setAge(int age) // Complex mutations deserve specific names void addPermission(Permission perm) void removeFromCart(Item item) void incrementRetryCount()

Common Naming Anti-Patterns

Recognizing anti-patterns is as important as knowing best practices. These naming mistakes are pervasive and costly.

Naming Anti-Patterns to Avoid

•Generic Verbs — handle(), process(), manage(), execute(), doStuff(). These words convey almost no meaning. What does handleRequest() do? Validate it? Route it? Transform it? Persist it?
•Misleading Names — getUser() that creates a user if not found violates semantic contracts. validate() that modifies data is worse than confusing—it's deceptive.
•Inconsistent Vocabulary — Using get, fetch, retrieve, and obtain interchangeably. Pick one. Consistency enables intuition.
•Technical Jargon — marshallData(), hydrateEntity(), reifyObject(). Unless your domain inherently uses these terms, prefer serialize, load, create.
•Abbreviations and Acronyms — calcMthlyPmt() is unreadable. calculateMonthlyPayment() is clear. Save keystrokes with autocomplete, not cryptic abbreviations.
•Hungarian Notation — strName, intAge, arrItems. Type information belongs in the type system, not in names. Modern IDEs make this obsolete.
•And/Or in Names — validateAndSave(), fetchOrCreate(). This is a code smell indicating the method does too much. Split into separate methods.
•Bool Parameter in Name — setEnabled(true) reads better as enable(). setVisible(false) reads better as hide(). Boolean parameters often indicate a method should be split.

Anti-Pattern Examples

•processData()
•handleEvent()
•doWork()
•manage()
•getData() (returns void)
•fetchOrCreate()
•getUserIfExistsOr...
•str_username

Preferred Alternatives

•transformToJson()
•routeToHandler()
•executeScheduledTask()
•startMonitoring()
•loadData() (performs action)
•find() + create() separately
•findUser() (nullable return)
•username

The 'And' Smell

When you're tempted to use 'And' or 'Or' in a method name, stop. This almost always indicates a Single Responsibility Principle violation. A method should do one thing. If you need both operations, expose two methods and let the caller compose them—or create a higher-level abstraction that explicitly represents the combined operation.

Consistency and Naming Systems

Individual method names matter, but systematic consistency matters more. A naming system creates predictability. When developers learn the patterns in one part of your API, they can predict method names across the entire API. Establishing a Naming System A naming system defines: Verb vocabulary — The specific verbs used and their precise meanings Grammatical patterns — How verbs, nouns, and modifiers combine Domain terminology — The nouns and concepts from the problem domain Exceptions — Documented deviations and their rationale

naming-system-example.md
Markdown
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
# API Naming System: Order Management
 
## Verb Vocabulary
 
| Verb | Meaning | Returns | Throws |
|------|---------|---------|--------|
| get | Retrieve by identifier | Entity (non-null) | NotFoundException |
| find | Search/filter | Entity? or List | Never |
| create | Construct new entity | Created entity | ValidationException |
| update | Modify existing entity | Updated entity | NotFoundException |
| delete | Remove entity | void | Never (idempotent) |
| submit | Transition to submitted state | void | InvalidStateException |
| cancel | Transition to cancelled state | void | InvalidStateException |
| archive | Move to archived state | void | InvalidStateException |
 
## Grammatical Patterns
 
- Retrieval: `{get|find}{Entity}[By{Criteria}]`
  - Examples: `getOrder()`, `findOrdersByCustomer()`, `findByStatus()`
  
- Creation: `create{Entity}`
  - Examples: `createOrder()`, `createLineItem()`
  
- State transitions: `{verb}{Entity}` or just `{verb}()` if context is clear
  - Examples: `submitOrder()`, `order.submit()`, `order.cancel()`
 
## Domain Terminology
 
- Use: Order, LineItem, Customer, Product, Shipment
- Avoid: Transaction, Entry, User (where Customer is meant), Item (where Product is meant)

The Power of Predictability With a documented naming system, developers can predict: getCustomer(id) exists because getOrder(id) exists findOrdersByCustomer(customerId) follows the findXByY pattern order.cancel() exists because order.submit() exists This predictability dramatically accelerates API adoption and reduces lookup friction.

Document Your Naming Conventions

Create a NAMING_CONVENTIONS.md file in your project. Document the verb vocabulary, grammatical patterns, and any domain-specific rules. Review new method names against this document in code reviews. This investment pays dividends as the team grows and the codebase evolves.

Context and Naming Scope

Method names don't exist in isolation—they exist within a context : the class or module where they're defined. Good naming leverages context to achieve clarity without redundancy. Avoid Redundant Context When a method is called on an object, the object's type is already known. Don't repeat it:

redundant.java
Java
1
2
3
4
5
6
7
8
9
10
11
// Redundant — class name repeated
class Order {
    void cancelOrder() { ... }
    void submitOrder() { ... }
    BigDecimal getOrderTotal() { ... }
    List<LineItem> getOrderLineItems() { ... }
}
 
// At call site:
order.cancelOrder();
order.getOrderTotal();

clean.java
Java
1
2
3
4
5
6
7
8
9
10
11
// Clean — context provides clarity
class Order {
    void cancel() { ... }
    void submit() { ... }
    BigDecimal getTotal() { ... }
    List<LineItem> getLineItems() { ... }
}
 
// At call site:
order.cancel();
order.getTotal();

When Context Is Insufficient Sometimes, context alone doesn't provide enough clarity. In these cases, additional qualification is appropriate: class User { // 'send' alone is ambiguous—send what? void sendVerificationEmail() { ... } void sendPasswordResetEmail() { ... } // 'update' alone is ambiguous—update what? void updatePassword(String newPassword) { ... } void updateProfilePhoto(Image photo) { ... } } Package/Module Context Beyond class context, package or module names also contribute to clarity: // In package com.example.payments class PaymentService { // 'process' is fine here—the package and class name // provide context that makes 'process' unambiguous void process(Payment payment) { ... } } // Would be unclear in a more generic package // In package com.example.core class Service { // process what? This needs qualification void process(Object thing) { ... } // BAD }

Read Method Calls at Call Sites

Always consider how a method name reads at the call site, not just at the definition site. The call site is where clarity matters most. paymentService.process(payment) reads clearly because the variable names provide context. Ensure your naming works well in typical call site scenarios.

System Design (LLD)Method Signature Design

Method Signature Design

LevelIntermediate

Duration60 mins

TopicMethod Signature Design

1 / 4

Method Naming Conventions

The Name Is the Interface

Before a single line of documentation is read, before parameter types are examined, before return values are considered—a method name is encountered. That name is not merely an identifier; it is a promise . It declares intent. It sets expectations. It either guides understanding or sows confusion. In the world of API design, method naming is not a trivial detail relegated to style guides and linting rules. It is the first act of communication between the API designer and every developer who will ever use that API. A well-named method reveals its purpose instantly. A poorly-named method creates friction that compounds across every invocation, every code review, every debugging session. Consider the difference between process() and validateAndSubmitOrder() . The former tells you almost nothing; the latter tells you almost everything. That distinction—multiplied across hundreds of methods in a codebase—is the difference between APIs that developers love and APIs that developers dread.

What You Will Master

By the end of this page, you will understand the foundational principles of method naming, recognize common anti-patterns, and apply proven naming strategies that make APIs self-documenting and intuitive. You'll think about naming the way Principal Engineers do—as a design decision with lasting consequences.

Why Method Names Matter

Method names are not merely labels—they are the primary mechanism for conveying design intent . When developers encounter your API, names are what they see first in autocomplete, what they search for, what they discuss in code reviews, and what they remember. The cognitive load imposed by poor naming accumulates across every interaction with your API. The Cost of Poor Naming Poor method names create a cascade of problems: Increased learning curve — Developers must read documentation for every method instead of inferring purpose from names. Higher defect rates — When names don't reflect behavior, developers make incorrect assumptions, leading to bugs. Reduced discoverability — In autocomplete scenarios, vague names don't surface when developers search for functionality. Code review friction — Reviewers must constantly verify that method names match their implementations. Maintenance burden — Future maintainers inherit confusion, often perpetuating or worsening naming inconsistencies.

Impact of Naming Quality Across the Development Lifecycle
Development Phase	Good Naming Impact	Poor Naming Impact
Discovery/Learning	Self-documenting, intuitive exploration	Requires documentation for every method
Implementation	Code reads like natural language	Constant back-and-forth with docs
Code Review	Intent is immediately apparent	Reviewers question every method call
Debugging	Call stacks reveal behavior flow	Method names obscure execution path
Maintenance	Changes are confidently localized	Fear of unintended side effects
Onboarding	New developers ramp up quickly	Tribal knowledge required to understand

The Naming Debt Compound Effect

Poor naming is a form of technical debt that compounds silently. Unlike performance issues that manifest as measurable slowdowns, naming debt manifests as slower development, more bugs, and developer frustration—all of which are harder to quantify but no less real.

Foundational Naming Principles

Effective method naming rests on several foundational principles that transcend specific programming languages or frameworks. These principles should guide every naming decision you make.

Core Naming Principles

•Reveal Intent, Not Implementation — A method name should describe what the method does, not how it does it. sendEmail() is better than useSmtpToTransmit(). Implementation may change; intent should remain stable.
•Be Precise, Not Vague — Avoid generic names like handle(), process(), manage(), or execute(). These words carry almost no semantic meaning. Prefer processPayment(), handleAuthenticationFailure(), or executeScheduledJob().
•Use Domain Vocabulary — Names should come from the problem domain, not technical jargon. If the business calls it an 'Order', don't call it a 'Transaction'. Ubiquitous language from Domain-Driven Design applies here.
•Maintain Consistent Conventions — If you use get for retrieval in one place, don't use fetch, retrieve, or obtain elsewhere. Consistency reduces cognitive load dramatically.
•Optimize for Readability, Not Brevity — A longer, clearer name is almost always better than a shorter, ambiguous one. calculateMonthlyInterestPayment() beats calcMIP().
•Consider the Call Site — Methods are read at call sites far more often than at definition sites. order.cancel() reads better than order.setCancelled(true).

The Grain of Truth in Brevity While we advocate for clarity over brevity, there's a legitimate concern about overly long names. The key is to achieve maximum clarity per character . Each word in a method name should add meaning. Remove words that don't contribute. For example, getUserFromDatabaseById() can be simplified to getUser() if the 'from database' part is implied by the class context and 'by ID' is implied by the parameter type. Context already communicates some information; don't repeat it in the name.

The Newspaper Test

Read your method call in the context of surrounding code. Does it read like a sentence in a newspaper article? Good names allow code to be read almost like prose: if (user.canAccessResource(document)) { audit.logAccessGranted(user, document); }

Verb-First Naming Patterns

In most programming languages, methods represent actions —things an object can do. Actions are naturally described with verbs. Therefore, the predominant convention is to start method names with a verb that describes the action being performed. Standard Verb Prefixes and Their Meanings Over decades of software development, certain verb prefixes have acquired standardized meanings. Deviating from these meanings creates confusion; adhering to them leverages developers' existing mental models.

Common Verb Prefixes and Their Semantic Contracts
Prefix	Semantic Meaning	Expectations	Example
`get`	Retrieve a value	No side effects, returns non-null or throws	`getUser(id)`
`find`	Search for a value	No side effects, may return null	`findUserByEmail(email)`
`set`	Assign a value	Mutates state, usually returns void	`setPassword(newPassword)`
`is/has/can`	Query boolean state	No side effects, returns boolean	`isActive()`, `hasPermission()`
`create`	Construct a new entity	Returns new object, may persist	`createOrder(items)`
`delete/remove`	Eliminate an entity	Mutates state, idempotent preferred	`deleteUser(id)`
`update`	Modify existing entity	Mutates state, typically partial	`updateProfile(changes)`
`compute/calculate`	Derive a value from inputs	Pure function, deterministic	`calculateTax(order)`
`validate`	Check correctness	No mutation, returns boolean or throws	`validateEmail(email)`
`parse`	Transform string to type	Pure function, may throw on bad input	`parseDate(dateString)`
`format`	Transform type to string	Pure function, deterministic	`formatCurrency(amount)`
`ensure/require`	Guarantee a condition	Throws if condition not met	`ensureAuthenticated()`
`try`	Attempt operation	Returns success/failure, doesn't throw	`tryParse(input)`
`initialize/init`	Set up object state	Called once, usually in lifecycle	`initialize(config)`
`dispose/close`	Release resources	Called for cleanup, idempotent	`dispose()`, `close()`

Semantic Precision Matters Notice the subtle but important distinction between get and find . A get method implies the entity is expected to exist; if it doesn't, an exception is thrown. A find method implies the entity may or may not exist; null (or Optional/Maybe) is a valid return value. This isn't arbitrary—it communicates intent at the call site : // Developer knows this will throw if user doesn't exist const user = userRepository.getUser(id); // Developer knows they need to handle the null case const user = userRepository.findUserByEmail(email); if (user === null) { // Handle missing user } When these semantic contracts are violated—e.g., a get method that returns null—developers write incorrect code based on correct assumptions about API conventions.

Language-Specific Conventions

Some languages have established variations. In Python, properties often use @property decorators instead of get_prefixes. In Ruby, boolean methods end with ? . In Kotlin, property access syntax is preferred. Always respect language-specific idioms while maintaining semantic clarity.

Naming Patterns for Different Method Types

Different categories of methods have evolved distinct naming patterns. Understanding these patterns helps maintain consistency and set correct expectations.

Accessor Methods (Getters) Accessors retrieve internal state without modification. They should: Start with get (or language-appropriate equivalent) Return a value (never void) Be side-effect free Be idempotent (same result on repeated calls, assuming no external mutation) // Good accessors String getName() int getAge() List<Order> getOrders() Optional<Address> getShippingAddress() // Boolean accessors use is/has/can boolean isActive() boolean hasOrders() boolean canEdit() Mutator Methods (Setters) Mutators modify internal state. They should: Start with set for simple property assignment Use more specific verbs for complex mutations Consider returning this for fluent APIs Consider returning the previous value if useful // Simple setters void setName(String name) void setAge(int age) // Fluent setters (return this) User setName(String name) Builder setAge(int age) // Complex mutations deserve specific names void addPermission(Permission perm) void removeFromCart(Item item) void incrementRetryCount()

Common Naming Anti-Patterns

Recognizing anti-patterns is as important as knowing best practices. These naming mistakes are pervasive and costly.

Naming Anti-Patterns to Avoid

•Generic Verbs — handle(), process(), manage(), execute(), doStuff(). These words convey almost no meaning. What does handleRequest() do? Validate it? Route it? Transform it? Persist it?
•Misleading Names — getUser() that creates a user if not found violates semantic contracts. validate() that modifies data is worse than confusing—it's deceptive.
•Inconsistent Vocabulary — Using get, fetch, retrieve, and obtain interchangeably. Pick one. Consistency enables intuition.
•Technical Jargon — marshallData(), hydrateEntity(), reifyObject(). Unless your domain inherently uses these terms, prefer serialize, load, create.
•Abbreviations and Acronyms — calcMthlyPmt() is unreadable. calculateMonthlyPayment() is clear. Save keystrokes with autocomplete, not cryptic abbreviations.
•Hungarian Notation — strName, intAge, arrItems. Type information belongs in the type system, not in names. Modern IDEs make this obsolete.
•And/Or in Names — validateAndSave(), fetchOrCreate(). This is a code smell indicating the method does too much. Split into separate methods.
•Bool Parameter in Name — setEnabled(true) reads better as enable(). setVisible(false) reads better as hide(). Boolean parameters often indicate a method should be split.

Anti-Pattern Examples

•processData()
•handleEvent()
•doWork()
•manage()
•getData() (returns void)
•fetchOrCreate()
•getUserIfExistsOr...
•str_username

Preferred Alternatives

•transformToJson()
•routeToHandler()
•executeScheduledTask()
•startMonitoring()
•loadData() (performs action)
•find() + create() separately
•findUser() (nullable return)
•username

The 'And' Smell

When you're tempted to use 'And' or 'Or' in a method name, stop. This almost always indicates a Single Responsibility Principle violation. A method should do one thing. If you need both operations, expose two methods and let the caller compose them—or create a higher-level abstraction that explicitly represents the combined operation.

Consistency and Naming Systems

Individual method names matter, but systematic consistency matters more. A naming system creates predictability. When developers learn the patterns in one part of your API, they can predict method names across the entire API. Establishing a Naming System A naming system defines: Verb vocabulary — The specific verbs used and their precise meanings Grammatical patterns — How verbs, nouns, and modifiers combine Domain terminology — The nouns and concepts from the problem domain Exceptions — Documented deviations and their rationale

naming-system-example.md
Markdown
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
# API Naming System: Order Management
 
## Verb Vocabulary
 
| Verb | Meaning | Returns | Throws |
|------|---------|---------|--------|
| get | Retrieve by identifier | Entity (non-null) | NotFoundException |
| find | Search/filter | Entity? or List | Never |
| create | Construct new entity | Created entity | ValidationException |
| update | Modify existing entity | Updated entity | NotFoundException |
| delete | Remove entity | void | Never (idempotent) |
| submit | Transition to submitted state | void | InvalidStateException |
| cancel | Transition to cancelled state | void | InvalidStateException |
| archive | Move to archived state | void | InvalidStateException |
 
## Grammatical Patterns
 
- Retrieval: `{get|find}{Entity}[By{Criteria}]`
  - Examples: `getOrder()`, `findOrdersByCustomer()`, `findByStatus()`
  
- Creation: `create{Entity}`
  - Examples: `createOrder()`, `createLineItem()`
  
- State transitions: `{verb}{Entity}` or just `{verb}()` if context is clear
  - Examples: `submitOrder()`, `order.submit()`, `order.cancel()`
 
## Domain Terminology
 
- Use: Order, LineItem, Customer, Product, Shipment
- Avoid: Transaction, Entry, User (where Customer is meant), Item (where Product is meant)

The Power of Predictability With a documented naming system, developers can predict: getCustomer(id) exists because getOrder(id) exists findOrdersByCustomer(customerId) follows the findXByY pattern order.cancel() exists because order.submit() exists This predictability dramatically accelerates API adoption and reduces lookup friction.

Document Your Naming Conventions

Create a NAMING_CONVENTIONS.md file in your project. Document the verb vocabulary, grammatical patterns, and any domain-specific rules. Review new method names against this document in code reviews. This investment pays dividends as the team grows and the codebase evolves.

Context and Naming Scope

Method names don't exist in isolation—they exist within a context : the class or module where they're defined. Good naming leverages context to achieve clarity without redundancy. Avoid Redundant Context When a method is called on an object, the object's type is already known. Don't repeat it:

redundant.java
Java
1
2
3
4
5
6
7
8
9
10
11
// Redundant — class name repeated
class Order {
    void cancelOrder() { ... }
    void submitOrder() { ... }
    BigDecimal getOrderTotal() { ... }
    List<LineItem> getOrderLineItems() { ... }
}
 
// At call site:
order.cancelOrder();
order.getOrderTotal();

clean.java
Java
1
2
3
4
5
6
7
8
9
10
11
// Clean — context provides clarity
class Order {
    void cancel() { ... }
    void submit() { ... }
    BigDecimal getTotal() { ... }
    List<LineItem> getLineItems() { ... }
}
 
// At call site:
order.cancel();
order.getTotal();

When Context Is Insufficient Sometimes, context alone doesn't provide enough clarity. In these cases, additional qualification is appropriate: class User { // 'send' alone is ambiguous—send what? void sendVerificationEmail() { ... } void sendPasswordResetEmail() { ... } // 'update' alone is ambiguous—update what? void updatePassword(String newPassword) { ... } void updateProfilePhoto(Image photo) { ... } } Package/Module Context Beyond class context, package or module names also contribute to clarity: // In package com.example.payments class PaymentService { // 'process' is fine here—the package and class name // provide context that makes 'process' unambiguous void process(Payment payment) { ... } } // Would be unclear in a more generic package // In package com.example.core class Service { // process what? This needs qualification void process(Object thing) { ... } // BAD }

Read Method Calls at Call Sites

Always consider how a method name reads at the call site, not just at the definition site. The call site is where clarity matters most. paymentService.process(payment) reads clearly because the variable names provide context. Ensure your naming works well in typical call site scenarios.

Method Naming Conventions

The Name Is the Interface

Why Method Names Matter

Foundational Naming Principles

Verb-First Naming Patterns

Naming Patterns for Different Method Types

Common Naming Anti-Patterns

Consistency and Naming Systems

Context and Naming Scope

There’s more to understand.

Method Naming Conventions

The Name Is the Interface

Why Method Names Matter

Foundational Naming Principles

Verb-First Naming Patterns

Naming Patterns for Different Method Types

Common Naming Anti-Patterns

Consistency and Naming Systems

Context and Naming Scope

There’s more to understand.