naming-cheatsheet_skill

Overview

This skill applies language-agnostic naming conventions using the A/HC/LC pattern to name variables, functions, and review code for naming consistency. It encodes short, intuitive, descriptive (S-I-D) principles and actionable verb/prefix guidance. Use it to enforce consistent, readable identifiers across any codebase or language. The guidance is practical for naming, refactoring, and team standards.

How this skill works

It inspects identifier roles and suggests names using the structure: optional prefix + action (A) + high context (HC) + optional low context (LC). It evaluates verb choice (get, set, reset, remove/delete, compose, handle) and prefix semantics (is/has/should, min/max, prev/next) to ensure intent is clear. It flags context duplication, inconsistent casing, non-English words, contractions, incorrect singular/plural usage, and mismatched boolean naming. Recommendations include concrete renames and rationale tied to the A/HC/LC pattern.

When to use it

• Creating new variables, functions, classes, or methods
• Reviewing code for naming consistency during PRs or audits
• Refactoring legacy code with unclear or inconsistent identifiers
• Defining team naming conventions or onboarding documentation
• Teaching naming best practices in code reviews or workshops

Best practices

• Follow the A/HC/LC order: prefix? + action + high context + low context?
• Prefer short, intuitive, and descriptive names (S-I-D) over clever or terse identifiers
• Be consistent with casing (camelCase, PascalCase, or snake_case) across the project
• Use correct verb semantics: pair remove/add and delete/create appropriately
• Use English words, avoid contractions and duplicated context inside class scopes
• Name booleans to reflect the actual condition (isDisabled vs isEnabled) and use clear prefixes

Example use cases

• Rename ambiguous variables (a, tmp, x) to descriptive names like postCount or userId
• Suggest function names following A/HC/LC: shouldDisplayMessage, getUserMessages, handleClickOutside
• Decide between remove vs delete when designing collection vs permanent operations
• Standardize boolean prefixes in a codebase (is/has/should) and correct inverted logic names
• Enforce singular vs plural for item vs collection variables during refactors