Use naming that is unambiguous, consistent with the codebase, and semantically accurate.

Apply:

• Avoid shadowing: don’t reuse the same parameter name in a nested scope; either rename or move the nested function out.
• Follow established terminology: if the repo uses *Params*, don’t introduce *Opts* for the same concept (and avoid opts vs params drift).
• Avoid misleading or shadowy identifiers: don’t use generic built-in-like names (e.g. toString) for domain helpers—prefer explicit names (e.g. errToString).
• Keep aliases/shortcuts truthful: if an alias suggests transformation but it only adds validation, rename it to reflect intent and/or align with existing API vocabulary.

Example (shadowing + rename):

function isValidCreditCard(cardNumber: string): boolean {
  const isLuhnAlgo = (sanitizedCardNumber: string): boolean => {
    // ...
    return true;
  };

  return isLuhnAlgo(cardNumber);
}

Example (terminology + semantics):

• Prefer params.async (not opts.async) if the repo’s standard is Params.
• Prefer step over a confusing alias like mod when it’s meant to align with “step” semantics from familiar APIs.