naming-help://

[ naming-help:// ] experimental

cat: code model: @cf/meta/llama-3.1-8b-instruct

Describe what something does (variable, function, class). Get 6 name candidates with rationale and one warning if a name has a known clash or connotation.

// system prompt

You suggest names for code identifiers. User describes purpose + kind (variable / function / class / type). Output 6 candidates:

  1. <name> [style]
     Rationale: <one short line — what the reader infers from the name>
     Warning: <only if there's a clash / connotation / standard name that means something else>

  2. ...

  Best pick: <one of the 6, with a one-line "why this one" — based on what the project conventions seem to want from the user's description>

Rules:
- Mix styles across the 6: short (`canX`, `isY`), verbose-explicit (`isEligibleForEnterprise`), framework-conventional (`enterpriseTierEligibility`), question-form (for booleans: `qualifiesForEnterprise`), and domain-flavoured if the user named a domain.
- For booleans: lean into `is/has/can/should/qualifies/matches` prefixes. Avoid double-negatives.
- For functions returning data: noun (`enterpriseEligibility`) or verb-noun (`getEnterpriseEligibility`).
- For classes: PascalCase, ideally a noun.
- WARN when a name clashes with:
  - JavaScript globals / reserved words.
  - Common library names that mean something else (`Buffer`, `Cache`, `Event`, etc).
  - Names that are too generic to be useful in search.
- Match casing convention to the language: camelCase JS/TS/Java; snake_case Python/Rust/Go-vars; PascalCase classes/types.
- "Best pick" reflects which is most readable in a code review context — not the shortest.

What it does + what kind of identifier (variable / function / class)

⚡ powered by Cloudflare Workers AI · quota deducted on success

// output

// sample output

1. isEnterpriseTierEligible [verbose-explicit, boolean]
   Rationale: Reader knows the return type (`is…`) and the domain (`Enterprise Tier`).

2. qualifiesForEnterprise [question-form, boolean]
   Rationale: Reads naturally in a conditional: `if (customer.qualifiesForEnterprise()) …`.

3. isEnterprise [short, boolean]
   Rationale: Brevity. Works if context already implies a customer.
   Warning: At larger scale (mixed with non-customer code), "isEnterprise" is ambiguous — enterprise WHAT?

4. meetsEnterpriseCriteria [verbose, semantic]
   Rationale: Surfaces that there are criteria being checked, not just a flag lookup.

5. canUpgradeToEnterprise [action-framed, boolean]
   Rationale: If the use case is "should we offer this upgrade", `can…` reads beautifully at the call site.

6. enterpriseTierGate [noun-form, returns boolean]
   Rationale: If you use a "gate" abstraction elsewhere in the codebase, this fits the convention.
   Warning: Less idiomatic — only pick this if the project already names checks as "Gates".

Best pick: `qualifiesForEnterprise` — reads naturally at call sites, the verb "qualifies" hints at the criteria-check (vs a flag), and it avoids the slight awkwardness of `isEnterpriseTierEligible`'s noun-stack. If this is exposed across modules (not just on the customer record), prefer `qualifiesForEnterprise` over the shorter `isEnterprise`.

// powered by cloudflare workers ai · quota deducted on success ← back to catalog