Naming Variables

Replace cryptic or generic variable names with descriptive alternatives that explain what the variable represents in your problem domain. Use names like `balance` instead of `x`, and `last_payment` instead of `xx` to make code self-documenting and easier to debug and maintain.

Use `is_` or `has_` prefixes for booleans (`is_valid`), plural forms for collections (`users`), uppercase with underscores for constants (`MAX_RETRIES`), and qualifiers at the end for computed values (`revenue_total`).

Balance descriptiveness with conciseness based on variable scope. Wider scopes need longer, more descriptive names; tighter scopes can use shorter names. Avoid abbreviations that sacrifice clarity; a name's length should match how often developers encounter it.

A name is too vague when it doesn't describe what the variable represents in your domain, relies on abbreviations, or uses generic terms like `data` or `value`. If you struggle to name something, it often signals an underlying design problem worth investigating.

Yes. This skill applies during design reviews or whenever readability is compromised by cryptic names or abbreviations, helping teams enforce consistent naming principles and catch clarity issues before they propagate.