Meaningful Method Names

1. Introduction

A meaningful method name clearly communicates what operation the method performs, what result it returns, or what condition it checks.

During a Pull Request review, reviewers should understand the purpose of a method without opening its implementation. If a method is named process(), handle(), or doTask(), the reviewer must inspect its body and every call site to understand its behavior.

Good method names make Java code easier to read, review, test, debug, and maintain.

2. What This Topic Means

A meaningful method name describes the method’s intent from the caller’s perspective.

Compare:

paymentService.process(paymentRequest);

With:

paymentService.authorizePayment(paymentRequest);

The second method immediately explains that the operation performs payment authorization.

For methods returning values, the name should describe the returned information:

BigDecimal calculateOutstandingBalance(String customerId);

For boolean methods, the name should read like a condition:

boolean isPaymentEligibleForRefund(Payment payment);

Method names should describe what the method does, not every internal implementation step.

3. Why It Matters in Real Projects

Readability

Call sites become self-explanatory:

if (userService.hasPermission(userId, Permission.UPDATE_ORDER)) {
    orderService.updateShippingAddress(orderId, request);
}

Maintainability

Developers can find the correct method and understand its responsibility more quickly.

Debugging

Clear names help developers follow stack traces and identify the failed business operation.

Reliability

Precise names reduce the chance that a developer calls the wrong method or misunderstands its side effects.

Team Development

Developers can work across services and modules without reading every implementation.

Performance

Naming does not directly improve runtime performance. However, a name such as loadAllTransactions() makes potentially expensive behavior visible during review.

Scalability

Meaningful names can reveal operations that may not scale, such as loading all records or making synchronous external calls.

4. Core Concept

A method name should communicate one primary intent.

Common naming patterns include:

Commands

Commands perform an action:

createCustomerAccount();
cancelOrder();
sendPaymentConfirmation();
updateInventoryQuantity();

Queries

Queries return information without unexpectedly changing state:

findCustomerById();
calculateOrderTotal();
getAvailableInventory();

Predicates

Predicates return boolean conditions:

isAccountActive();
hasSufficientBalance();
canCancelOrder();
shouldSendNotification();

Conversions

Conversion methods explain the source and target:

toCustomerResponse();
mapToPaymentEntity();
convertToLocalDateTime();

Validation

Validation names should reveal whether the method returns a result or throws an exception:

boolean isValidPaymentRequest(PaymentRequest request);
void validatePaymentRequest(PaymentRequest request);

The first returns a boolean. The second commonly throws a validation exception when input is invalid.

5. Important Rules

• Use verbs or verb phrases for methods that perform actions.
• Use nouns only where Java conventions make them appropriate, such as record accessors.
• Describe the business operation, not a vague activity.
• Use is, has, can, or should for boolean-returning methods.
• Distinguish methods that return a boolean from methods that throw validation exceptions.
• Make side effects visible when they are important.
• Use find when a result may not exist.
• Avoid using get for expensive database or external API operations when it hides important behavior.
• Use consistent terminology throughout the application.
• Avoid implementation-specific names if the implementation may change.
• Do not claim that a method performs more than it actually does.
• Rename the method when its responsibility changes.
• Avoid names that require comments to explain their meaning.
• Keep names concise, but do not sacrifice clarity.
• Follow established framework conventions where applicable.

6. Bad Code Example

@Service
public class PaymentService {

    private final PaymentRepository paymentRepository;
    private final FraudClient fraudClient;
    private final NotificationService notificationService;

    public PaymentService(
            PaymentRepository paymentRepository,
            FraudClient fraudClient,
            NotificationService notificationService) {
        this.paymentRepository = paymentRepository;
        this.fraudClient = fraudClient;
        this.notificationService = notificationService;
    }

    public Payment doIt(PaymentRequest request) {
        check(request);

        FraudResult fraudResult = getData(request);

        if (!fraudResult.isApproved()) {
            return save(request, PaymentStatus.REJECTED);
        }

        Payment payment = save(request, PaymentStatus.APPROVED);
        process(payment);

        return payment;
    }

    private void check(PaymentRequest request) {
        if (request == null || request.amount() == null) {
            throw new IllegalArgumentException("Invalid request");
        }
    }

    private FraudResult getData(PaymentRequest request) {
        return fraudClient.check(request.customerId(), request.amount());
    }

    private Payment save(PaymentRequest request, PaymentStatus status) {
        Payment payment = new Payment();
        payment.setCustomerId(request.customerId());
        payment.setAmount(request.amount());
        payment.setStatus(status);

        return paymentRepository.save(payment);
    }

    private void process(Payment payment) {
        notificationService.send(payment);
    }
}

7. Problems in the Bad Code

doIt() Hides the Main Operation

The public method does not indicate whether it creates, authorizes, captures, refunds, or cancels a payment.

check() Is Ambiguous

The name does not explain:

• What is being checked
• What rules are applied
• Whether it returns a result
• Whether it throws an exception

getData() Hides an External Call

The method actually calls an external fraud-detection service. The name hides potentially slow and failure-prone network activity.

save() Lacks Business Context

The method creates and persists a payment record, but its name communicates only the persistence step.

process() Hides a Side Effect

The method sends a notification. A developer may call it without realizing that an external message or email could be triggered.

Weak Stack Traces

A production stack trace containing doIt, check, getData, and process provides little diagnostic value.

Bug Risk

A developer may reuse process() expecting it to perform payment processing when it only sends a notification.

Maintenance Risk

Future developers must inspect every method body before safely changing or reusing it.

8. Code Review Findings

A senior reviewer should notice that:

• The public API does not communicate the payment operation.
• Method names hide important external and database interactions.
• check() throws an exception, but its name sounds like a boolean query.
• getData() does not reveal that fraud evaluation is being requested.
• process() has a notification side effect that is invisible at the call site.
• save() performs object creation and persistence.
• The method names would make logs, traces, and monitoring spans difficult to interpret.
• Business terminology is missing from the service.
• The public method name provides no useful search term for developers investigating payment authorization.

9. Reviewer Comment Example

Could we rename doIt() to describe the actual business operation, such as authorizePayment()?

check() throws an exception when the request is invalid. Please consider validatePaymentRequest() so its behavior is clearer.

getData() performs an external fraud-service call. A name such as evaluateFraudRisk() would make the network interaction and purpose easier to understand.

process() only sends an approval notification. Could we rename it to sendPaymentApprovalNotification() to expose that side effect?

The save() method also creates the payment entity. Please use a name that reflects the complete operation, such as createAndSavePayment().

10. Improved Code

@Service
public class PaymentAuthorizationService {

    private final PaymentRepository paymentRepository;
    private final FraudClient fraudClient;
    private final NotificationService notificationService;

    public PaymentAuthorizationService(
            PaymentRepository paymentRepository,
            FraudClient fraudClient,
            NotificationService notificationService) {
        this.paymentRepository = paymentRepository;
        this.fraudClient = fraudClient;
        this.notificationService = notificationService;
    }

    public Payment authorizePayment(PaymentRequest paymentRequest) {
        validatePaymentRequest(paymentRequest);

        FraudResult fraudEvaluation = evaluateFraudRisk(paymentRequest);

        if (!fraudEvaluation.isApproved()) {
            return createAndSavePayment(
                    paymentRequest,
                    PaymentStatus.REJECTED
            );
        }

        Payment approvedPayment = createAndSavePayment(
                paymentRequest,
                PaymentStatus.APPROVED
        );

        sendPaymentApprovalNotification(approvedPayment);

        return approvedPayment;
    }

    private void validatePaymentRequest(PaymentRequest paymentRequest) {
        if (paymentRequest == null) {
            throw new IllegalArgumentException(
                    "Payment request must not be null"
            );
        }

        if (paymentRequest.amount() == null) {
            throw new IllegalArgumentException(
                    "Payment amount must not be null"
            );
        }
    }

    private FraudResult evaluateFraudRisk(PaymentRequest paymentRequest) {
        return fraudClient.check(
                paymentRequest.customerId(),
                paymentRequest.amount()
        );
    }

    private Payment createAndSavePayment(
            PaymentRequest paymentRequest,
            PaymentStatus paymentStatus) {

        Payment payment = new Payment();
        payment.setCustomerId(paymentRequest.customerId());
        payment.setAmount(paymentRequest.amount());
        payment.setStatus(paymentStatus);

        return paymentRepository.save(payment);
    }

    private void sendPaymentApprovalNotification(Payment approvedPayment) {
        notificationService.send(approvedPayment);
    }
}

11. Improved Code Explanation

• PaymentAuthorizationService identifies the service’s business responsibility.
• authorizePayment() describes the public operation.
• validatePaymentRequest() communicates that invalid input causes validation failure.
• evaluateFraudRisk() explains the purpose of the external call.
• createAndSavePayment() makes both entity creation and persistence visible.
• sendPaymentApprovalNotification() exposes the notification side effect.
• Method calls now form a readable sequence of business operations.
• Stack traces and monitoring data will contain useful operation names.
• Future developers can understand the workflow without opening every private method.

12. Bad Code vs Improved Code

13. Real Project Scenario

A healthcare application processes clinical document uploads.

The original service contains methods such as:

handle();
check();
save();
send();

A production incident occurs because an uploaded clinical document is stored but never sent for virus scanning.

The operations would be easier to review and monitor if they were named:

validateClinicalDocument();
scanDocumentForMalware();
storeClinicalDocument();
publishDocumentProcessingEvent();

Clear method names help developers verify the complete workflow and identify exactly which operation failed.

14. Production Impact

Unclear method names can indirectly cause:

• Developers calling the wrong operation
• Important validation being skipped
• Unexpected database updates
• Duplicate external API calls
• Notifications being sent unintentionally
• Incorrect transaction boundaries
• Slow incident investigation
• Misleading logs and monitoring traces
• Regression bugs during refactoring
• Security-sensitive behavior being overlooked

The name itself does not execute incorrect logic, but it can hide behavior that developers need to understand before safely using or changing the method.

15. Common Developer Mistakes

Using Generic Action Names

process();
handle();
execute();
perform();
doWork();
runTask();

These names may be acceptable only when the surrounding abstraction already provides precise context.

Misusing get

getAllCustomerTransactions();

If this performs an expensive database query, findAllCustomerTransactions() or loadCustomerTransactions() may communicate the behavior more clearly.

Misleading Predicate Names

boolean validateOrder();

Does it return true, throw an exception, or modify the order?

Prefer:

boolean isOrderValid();

Or:

void validateOrder();

Hiding Side Effects

customerService.getCustomer(customerId);

This name is misleading if the method also creates the customer when no record exists.

A better name is:

findOrCreateCustomer(customerId);

Naming Methods After Implementation

readCustomerUsingJdbc();

If JDBC is later replaced with JPA, the name becomes incorrect. Prefer a business-oriented name such as:

findCustomerById();

Using Overly Long Names

validateOrderAndCalculateTotalAndSaveOrderAndSendEmail();

This indicates that the method probably has too many responsibilities.

Inconsistent Terminology

Using removeCustomer(), deleteUser(), and deactivateClient() for the same business operation creates confusion.

Keeping Old Names After Logic Changes

A method named calculateTax() may later calculate tax and shipping. The name then becomes incomplete or misleading.

16. Edge Cases

Missing Results

Use method names that communicate optional results:

Optional<Customer> findCustomerById(String customerId);

Avoid names that imply guaranteed existence:

Customer getCustomer(String customerId);

unless the method contract guarantees a result or throws a clearly documented exception.

Empty Collections

A method named findActiveOrders() should clearly return an empty collection when no records match rather than returning null.

Validation Behavior

Distinguish between:

boolean isValidCustomer(Customer customer);

And:

void validateCustomer(Customer customer);

The first should return a boolean. The second commonly throws an exception.

Duplicate Operations

A method named createOrder() should not silently return an existing order unless idempotency is part of its documented contract.

A more precise name may be:

createOrderIfAbsent();

Exception Scenarios

A name such as sendNotification() may hide retry behavior. If retry semantics matter to callers, a more specific contract or documentation may be required.

Concurrency

Names should expose atomic intent where relevant:

reserveInventoryIfAvailable();

The name is clearer than separate calls such as:

isInventoryAvailable();
reserveInventory();

The combined name signals that checking and reserving may need to happen atomically.

17. Performance Considerations

Method names do not change time or space complexity, but they can reveal expensive behavior.

Compare:

customerService.getCustomers();

With:

customerService.loadAllCustomersWithOrderHistory();

The second name makes it easier for a reviewer to question:

• Whether all customers must be loaded
• Whether order history is fetched eagerly
• Whether pagination is required
• Whether the operation causes excessive memory use
• Whether an N+1 query problem is possible

External calls should also be identifiable:

fetchExchangeRateFromProvider();

This is clearer than:

getRate();

Method names cannot replace performance documentation, metrics, or profiling, but they can prevent expensive behavior from being hidden behind innocent-looking APIs.

18. Security Considerations

Meaningful method names help reviewers identify security-sensitive operations.

Compare:

check(userId);

With:

verifyUserCanAccessMedicalRecord(userId, recordId);

The improved name exposes the authorization requirement.

Security-related names should distinguish:

authenticateUser();
authorizePaymentAccess();
validateJwtSignature();
sanitizeFileName();
encryptAccountNumber();
maskSensitiveDataForLogging();

Avoid misleading names such as:

validateToken();

if the method only checks token format but does not verify the signature, issuer, audience, or expiration.

A security-sensitive method name must accurately represent its guarantees. Naming a method sanitizeInput() does not make it secure if it performs incomplete sanitization.

19. Testing Considerations

Tests should verify the contract implied by the method name.

Positive Test

@Test
void authorizePaymentShouldApproveLowRiskPayment() {
    PaymentRequest paymentRequest = createLowRiskPaymentRequest();

    Payment authorizedPayment =
            paymentAuthorizationService.authorizePayment(paymentRequest);

    assertEquals(PaymentStatus.APPROVED, authorizedPayment.getStatus());
}

Negative Test

Verify that validatePaymentRequest() rejects a missing amount.

Boundary Test

Test:

• Zero payment amount
• Maximum supported payment amount
• Fraud score at the approval boundary

Exception Test

Verify behavior when:

• Fraud service is unavailable
• Repository persistence fails
• Notification delivery fails

Interaction Test

Verify that the method name matches its side effects:

verify(fraudClient).check(anyString(), any(BigDecimal.class));
verify(paymentRepository).save(any(Payment.class));
verify(notificationService).send(any(Payment.class));

Naming Tests Clearly

Test names should also express behavior:

shouldRejectPaymentWhenFraudEvaluationFails();

Avoid:

testProcess();
testMethod1();

20. Refactoring Guidelines

To rename a method safely:

1. Understand its current behavior and side effects.
2. Inspect every call site.
3. Check whether it overrides or implements another method.
4. Check whether it is used through reflection.
5. Check Spring Expression Language references.
6. Check scheduled-job and event-listener configuration.
7. Check template, workflow, or rule-engine references.
8. Check controller routes and serialization behavior.
9. Use IDE rename refactoring.
10. Run unit and integration tests.
11. Avoid changing behavior during a naming-only refactor.
12. Update logs, metrics, documentation, and tests where appropriate.
13. Consider temporary delegation when changing a public API.
14. Mark the old method as deprecated if external consumers need migration time.

Example:

@Deprecated
public Payment process(PaymentRequest request) {
    return authorizePayment(request);
}

The compatibility method can be removed after all consumers migrate.

21. Best Practices

• Use find for searches that may return no result.
• Use get only when it matches the project’s established contract.
• Use create, update, delete, cancel, or approve for explicit commands.
• Use calculate for derived values.
• Use validate for operations that enforce rules and may throw exceptions.
• Use is, has, can, or should for predicates.
• Use to... or mapTo... for conversions.
• Make external communication visible where important.
• Expose significant side effects in the method name.
• Use the same domain language used in requirements and API contracts.
• Keep method names aligned with actual behavior.
• Prefer a precise name over an explanatory comment.
• Treat difficulty naming a method as a possible sign that it has multiple responsibilities.

22. Practices to Avoid

• doIt() because it communicates no intent.
• process() when the actual operation can be named precisely.
• handle() outside a clearly defined handler abstraction.
• getData() because neither the data nor its source is identified.
• check() because its condition and failure behavior are unclear.
• manage() because it often hides multiple responsibilities.
• executeBusinessLogic() because it adds no useful business meaning.
• Predicate names that do not read as conditions.
• Method names that promise validation the implementation does not perform.
• Names that hide persistence, network calls, or other important side effects.
• Names containing implementation details likely to change.
• Very long names that reveal an oversized method.
• Reusing the same generic name for unrelated operations.

23. Code Review Checklist

• Does the method name clearly describe its primary responsibility?
• Can its purpose be understood without opening the implementation?
• Does an action method use an appropriate verb?
• Does a boolean method read like a condition?
• Does a validation method clearly indicate whether it returns a result or throws?
• Does the name expose important side effects?
• Does the name accurately represent database or external API behavior?
• Does find or get match the absence behavior?
• Does the method name match its current implementation?
• Is business terminology consistent with the rest of the project?
• Is the name free from unclear abbreviations?
• Is the method name focused, or does it reveal multiple responsibilities?
• Could the name mislead another developer into calling the method incorrectly?
• Would the method name be useful in logs, stack traces, and monitoring spans?
• Will renaming affect interfaces, reflection, Spring configuration, or external consumers?
• Is an expensive operation hidden behind an innocent-looking name?
• Does a security-related name accurately describe the protection performed?

24. Common Pull Request Review Comments

1. > Could we rename process() to describe the business operation, such as cancelOrder()?

1. > checkUser() throws when access is denied. Please consider verifyUserCanUpdateOrder() so the authorization behavior is explicit.

1. > This method performs a remote API call. A name such as fetchCreditScoreFromProvider() would make that cost visible.

1. > getCustomer() creates a new customer when no record exists. Could we rename it to findOrCreateCustomer()?

1. > Since this method returns a boolean, isPaymentEligibleForRefund() would read more clearly than validateRefund().

1. > save() also publishes an event. Please expose that side effect in the method contract or separate the responsibilities.

1. > The method is named validateToken(), but it only checks whether the token is present. Please rename it or implement the complete validation implied by the current name.

1. > calculateInvoice() also persists the invoice and sends an email. Consider extracting these operations into focused methods.

1. > Could we replace getData() with a domain-specific name describing the returned information?

1. > The name still refers to deletion, but the implementation now performs a soft deactivation. Please update the name to match the behavior.

25. Code Review Exercise

Review the following healthcare-service code:

@Service
public class PatientRecordService {

    private final PatientRepository patientRepository;
    private final AuditService auditService;
    private final NotificationClient notificationClient;

    public PatientRecordService(
            PatientRepository patientRepository,
            AuditService auditService,
            NotificationClient notificationClient) {
        this.patientRepository = patientRepository;
        this.auditService = auditService;
        this.notificationClient = notificationClient;
    }

    public Patient doTask(String id, PatientUpdateRequest request) {
        check(id, request);

        Patient patient = get(id);
        change(patient, request);
        save(patient);
        process(patient);

        return patient;
    }

    private void check(String id, PatientUpdateRequest request) {
        if (id == null || request == null) {
            throw new IllegalArgumentException("Invalid");
        }
    }

    private Patient get(String id) {
        return patientRepository.findById(id)
                .orElseThrow(() -> new IllegalArgumentException("Missing"));
    }

    private void change(Patient patient, PatientUpdateRequest request) {
        patient.setPhoneNumber(request.phoneNumber());
        patient.setEmergencyContact(request.emergencyContact());
    }

    private void save(Patient patient) {
        patientRepository.save(patient);
        auditService.record(patient);
    }

    private void process(Patient patient) {
        notificationClient.send(patient);
    }
}

Identify:

• Vague method names
• Hidden database operations
• Hidden side effects
• Misleading validation behavior
• Security and privacy risks
• Maintainability problems
• Appropriate replacement names

Do not reveal the solution until completing your own review.

26. Exercise Solution

Review Findings

• doTask() does not identify the patient-record operation.
• check() does not explain what is validated or that it throws an exception.
• get() hides a database lookup and exception behavior.
• change() does not explain which patient information is updated.
• save() also writes an audit record, so its name is incomplete.
• process() sends a notification but hides the external interaction.
• The notification may expose sensitive patient information if the complete entity is transmitted.
• The audit method receives the complete patient entity, which may record unnecessary sensitive data.
• The exception messages are too vague for debugging.
• The method name does not reveal the complete workflow.

Improved Code

@Service
public class PatientContactUpdateService {

    private final PatientRepository patientRepository;
    private final AuditService auditService;
    private final NotificationClient notificationClient;

    public PatientContactUpdateService(
            PatientRepository patientRepository,
            AuditService auditService,
            NotificationClient notificationClient) {
        this.patientRepository = patientRepository;
        this.auditService = auditService;
        this.notificationClient = notificationClient;
    }

    @Transactional
    public Patient updatePatientContactInformation(
            String patientId,
            PatientUpdateRequest updateRequest) {

        validatePatientContactUpdate(patientId, updateRequest);

        Patient patient = findPatientOrThrow(patientId);

        applyContactInformationChanges(patient, updateRequest);

        Patient updatedPatient = patientRepository.save(patient);

        recordPatientContactUpdate(patientId);
        sendContactUpdateConfirmation(patientId);

        return updatedPatient;
    }

    private void validatePatientContactUpdate(
            String patientId,
            PatientUpdateRequest updateRequest) {

        if (patientId == null || patientId.isBlank()) {
            throw new IllegalArgumentException(
                    "Patient ID must not be blank"
            );
        }

        if (updateRequest == null) {
            throw new IllegalArgumentException(
                    "Patient update request must not be null"
            );
        }
    }

    private Patient findPatientOrThrow(String patientId) {
        return patientRepository.findById(patientId)
                .orElseThrow(() ->
                        new PatientNotFoundException(patientId));
    }

    private void applyContactInformationChanges(
            Patient patient,
            PatientUpdateRequest updateRequest) {

        patient.setPhoneNumber(updateRequest.phoneNumber());
        patient.setEmergencyContact(updateRequest.emergencyContact());
    }

    private void recordPatientContactUpdate(String patientId) {
        auditService.recordContactUpdate(patientId);
    }

    private void sendContactUpdateConfirmation(String patientId) {
        notificationClient.sendContactUpdateConfirmation(patientId);
    }
}

Why These Changes Are Useful

• updatePatientContactInformation() describes the complete use case.
• validatePatientContactUpdate() identifies the validation scope.
• findPatientOrThrow() communicates both lookup and absence behavior.
• applyContactInformationChanges() describes the in-memory modification.
• Persistence remains explicit through patientRepository.save().
• Audit and notification side effects are separate and visible.
• Narrower audit and notification methods reduce unnecessary patient-data exposure.
• @Transactional makes the database transaction expectation visible.
• Domain-specific exceptions provide clearer production diagnostics.

27. Interview Perspective

Interviewers may ask candidates to review a service containing methods such as:

process();
handle();
check();
getData();
save();

A strong candidate should explain:

• Why the names hide business intent
• How names affect call-site readability
• How boolean and validation methods should differ
• Why side effects should be visible
• Why external calls should not be disguised as simple getters
• How method names improve stack traces and monitoring
• When renaming could affect framework or API behavior
• Why difficulty naming a method may indicate multiple responsibilities

Senior candidates should also discuss backward compatibility when renaming public methods.

28. Interview Questions and Answers

Basic Question

Question: What makes a method name meaningful?

Answer: A meaningful method name communicates the method’s primary intent, expected result, or condition without requiring the reader to inspect its implementation.

Intermediate Question

Question: How should boolean-returning methods usually be named?

Answer: They should read like conditions and commonly begin with is, has, can, or should, such as isOrderCancelable() or hasUpdatePermission().

Advanced Question

Question: Why can renaming a Java method be risky even when its implementation remains unchanged?

Answer: The method may be part of a public API, implement an interface, override a superclass method, or be referenced through reflection, Spring configuration, expressions, templates, schedulers, or external consumers.

Scenario-Based Question

Question: A method named getCustomer() calls an external API and may take several seconds. What would you recommend?

Answer: Use a name such as fetchCustomerFromExternalProvider() if the external interaction matters to callers. Also consider timeout, retry, caching, and failure-handling requirements.

Code-Review Question

Question: What is wrong with a method named validatePayment() that returns false for invalid input in some cases but throws exceptions in others?

Answer: Its contract is unclear and inconsistent. The team should choose a predictable design, such as isPaymentValid() returning a boolean or validatePayment() consistently throwing a validation exception.

Real-Project Question

Question: A method named saveOrder() saves the order, decreases inventory, and publishes an event. What should a reviewer suggest?

Answer: The reviewer should question whether the method has multiple responsibilities. The orchestration method could be named after the use case, such as placeOrder(), with focused operations for persistence, inventory reservation, and event publication.

29. Quick Rule to Remember

A method name should tell the caller what will happen without forcing them to read the method body.

30. Final Takeaway

Developers should name methods according to their business intent, result, condition, or visible side effect.

Reviewers should verify that:

• The method name matches its actual behavior.
• Boolean and validation contracts are clear.
• Database and external calls are not misleadingly hidden.
• Security-sensitive operations accurately describe their guarantees.
• Generic names are replaced with domain-specific names.
• Overly long names are investigated as possible responsibility problems.

Production code should avoid vague names such as doIt(), process(), handle(), check(), and getData() when the actual operation can be described precisely.