Fluent Naming for Boolean Methods
debt(d3/e1/b3/t5)
Closest to 'default linter catches the common case' (d3). The detection_hints list phpcs, phpmd, and phpstan as tools, and the automated flag is yes. phpcs/phpmd can flag boolean methods missing is/has/can prefixes and inconsistent verb prefixes as a common pattern, placing this squarely at the default linter level rather than requiring a specialist tool.
Closest to 'one-line patch or single-call swap' (e1). The quick_fix confirms this: rename the method and update its call sites. For a boolean method rename like active() → isActive(), this is a straightforward find-and-replace or IDE rename refactor, typically a single mechanical operation per method.
Closest to 'localised tax' (b3). The applies_to scope covers web, cli, and queue-worker contexts, which is broad, but naming conventions are a localised stylistic tax. They affect readability and onboarding effort within a codebase but don't create architectural gravity or constrain future choices in a structural way. Each violation is self-contained.
Closest to 'notable trap' (t5). The misconception field reveals the core trap: developers believe method names just need to describe what the method does, missing that context and intent matter (e.g., process() vs processPayment()). The common_mistakes also include methods whose names lie about their behaviour (save() that sends email), which is a documented gotcha that most developers learn after encountering confusing bugs. This is a well-known pitfall but not one that contradicts analogous concepts in other ecosystems.
Also Known As
TL;DR
Explanation
Boolean method names should read naturally in conditionals: if ($user->isActive()), if ($order->hasDiscount()), if ($role->canPublish()). Established prefixes: is (current state — isVerified, isExpired), has (possession — hasPermission, hasBillingAddress), can (capability — canEdit, canDelete), should (recommendation — shouldRedirect), was (past state — wasDelivered, wasCancelled). Avoid negation in names (isNotActive, hasNoItems) — double negatives in conditions such as if (!$order->hasNoItems()) are cognitively taxing. PHPStan and Psalm can enforce bool return types on methods with these prefixes via custom rules.
Common Misconception
Why It Matters
Common Mistakes
- Inconsistent verb prefixes: fetchUser(), getOrder(), retrieveProduct() — pick one verb and stick to it.
- Boolean methods without is/has/can prefix: $user->active() instead of $user->isActive().
- Class names that are verbs: UserProcessor, DataHandler — classes should be nouns.
- Method names that lie: save() that also sends an email — names must match behaviour.
Code Examples
// Inconsistent naming — team uses different conventions:
class UserManager { // 'Manager' is vague
function fetchUser() {} // fetch
function getOrder() {} // get
function loadProduct() {} // load — all mean the same thing
function active() {} // Should be isActive()
function do() {} // Meaningless
}// Fluent interface — method chaining returns \$this
class QueryBuilder {
public function select(string ...\$cols): static {
\$this->columns = \$cols; return \$this;
}
public function from(string \$table): static {
\$this->table = \$table; return \$this;
}
public function where(string \$cond): static {
\$this->conditions[] = \$cond; return \$this;
}
public function limit(int \$n): static {
\$this->limit = \$n; return \$this;
}
public function get(): array {
return \$this->db->query(\$this->toSql());
}
}
// Usage reads like English:
\$users = \$query
->select('id', 'name', 'email')
->from('users')
->where('active = 1')
->limit(20)
->get();