home / skills / develite98 / angular-best-practices / the-art-of-naming

the-art-of-naming skill

/skills/the-art-of-naming

This skill enforces a concise, self-documenting naming approach for TypeScript and Angular code, improving readability and maintainability across variables,

npx playbooks add skill develite98/angular-best-practices --skill the-art-of-naming

Review the files below or copy the command above to add this skill to your agents.

Files (10)
SKILL.md
3.8 KB
---
name: the-art-of-naming
description: Comprehensive naming convention guide for TypeScript and Angular applications. Covers casing rules (camelCase, PascalCase, UPPER_CASE), prefix conventions (I for interfaces, _ for private, T for generics), boolean naming, the S-I-D principle (Short, Intuitive, Descriptive), context duplication, and structured naming patterns (P/HC/LC for variables, A/HC/LC for functions). Use when writing, reviewing, or refactoring TypeScript code. Triggers on tasks involving naming, variables, functions, interfaces, or code style.
license: MIT
metadata:
  author: community
  version: "1.0.0"
---

# The Art of Naming

Naming things is hard. This guide provides a structured methodology for naming variables, functions, classes, interfaces, and everything in between — producing code that is self-documenting, consistent, and readable.

## When to Apply

Reference these guidelines when:
- Naming new variables, functions, classes, interfaces, or types
- Reviewing code for naming consistency
- Refactoring code to improve readability
- Setting up linting rules for a new project
- Onboarding new team members to the codebase conventions

## Core Principles

- **S-I-D** — Every name must be **S**hort, **I**ntuitive, and **D**escriptive
- **No Contractions** — `onItemClick`, never `onItmClk`
- **Correct Casing** — camelCase for members, PascalCase for types, UPPER_CASE for constants
- **Meaningful Prefixes** — `I` for interfaces, `_` for private, `is/has/should` for booleans
- **No Context Duplication** — `MenuItem.handleClick()`, not `MenuItem.handleMenuItemClick()`
- **Structured Patterns** — P/HC/LC for variables, A/HC/LC for functions
- **Correct Action Verbs** — `get` (sync), `fetch` (async), `remove` (collection), `delete` (permanent)

## Rule Categories by Priority

| Priority | Rule | Impact | File |
|----------|------|--------|------|
| 1 | Casing Convention | CRITICAL | `naming-casing-convention` |
| 2 | S-I-D + No Contractions | CRITICAL | `naming-sid` |
| 3 | Prefix Conventions | HIGH | `naming-prefix-convention` |
| 4 | Boolean Naming | HIGH | `naming-boolean` |
| 5 | Context Duplication | HIGH | `naming-context-duplication` |
| 6 | Function Naming (A/HC/LC) | HIGH | `naming-function-pattern` |
| 7 | Variable Naming (P/HC/LC) | MEDIUM | `naming-variable-pattern` |

## Quick Reference

### 1. Casing Convention (CRITICAL)

- `naming-casing-convention` - camelCase for variables/functions, PascalCase for classes/enums/types, UPPER_CASE for exported constants

### 2. S-I-D + No Contractions (CRITICAL)

- `naming-sid` - Names must be Short, Intuitive, Descriptive — never use contractions

### 3. Prefix Conventions (HIGH)

- `naming-prefix-convention` - `I` for interfaces, `_` for private members, `T`/`R`/`U`/`V`/`K` for generics

### 4. Boolean Naming (HIGH)

- `naming-boolean` - Prefix booleans with `is`/`has`/`should`/`can`, keep names positive

### 5. Context Duplication (HIGH)

- `naming-context-duplication` - Don't repeat class/component name in member names

### 6. Function Naming (HIGH)

- `naming-function-pattern` - A/HC/LC pattern + correct action verbs (get/set/fetch/remove/delete/compose/handle)

### 7. Variable Naming (MEDIUM)

- `naming-variable-pattern` - P/HC/LC pattern for structured, predictable variable names

## How to Use

Read individual rule files for detailed explanations and code examples:

```
rules/naming-casing-convention.md
rules/naming-sid.md
rules/naming-prefix-convention.md
rules/naming-boolean.md
rules/naming-context-duplication.md
rules/naming-function-pattern.md
rules/naming-variable-pattern.md
```

Each rule file contains:
- Brief explanation of why it matters
- Incorrect code examples with explanation
- Correct code examples with explanation
- Summary tables and references

## Full Compiled Document

For the complete guide with all rules expanded: `AGENTS.md`

Overview

This skill is a comprehensive naming convention guide for TypeScript and Angular projects that produces consistent, self-documenting code. It codifies casing rules, prefix conventions, boolean naming, the S-I-D principle (Short, Intuitive, Descriptive), and structured naming patterns to improve readability and reduce review friction.

How this skill works

The skill inspects names for variables, functions, classes, interfaces, enums, constants, and generics and flags deviations from the ruleset. It enforces casing (camelCase, PascalCase, UPPER_CASE), prefix rules (I for interfaces, _ for private, T for generics), boolean prefixes, context duplication checks, and P/HC/LC or A/HC/LC structured patterns for variables and functions. Use it during writing, review, refactor, or lint configuration to standardize names across a codebase.

When to use it

  • Naming new variables, functions, classes, interfaces, types, or constants
  • Reviewing pull requests to validate naming consistency
  • Refactoring code to make intent and scope clearer
  • Defining project linting and style rules
  • Onboarding team members to a shared naming standard

Best practices

  • Apply S-I-D: choose names that are Short, Intuitive, and Descriptive
  • Use correct casing: camelCase for members, PascalCase for types, UPPER_CASE for exported constants
  • Prefix booleans with is/has/should/can and keep names positive
  • Avoid repeating context: don’t include the class/component name in its member names
  • Follow structured patterns: P/HC/LC for variables; A/HC/LC for functions
  • Use precise action verbs: get (sync), fetch (async), remove (collection), delete (permanent)

Example use cases

  • Changing inconsistent names in a legacy Angular service during refactor
  • Setting up lint rules for a new TypeScript monorepo to prevent style drift
  • Reviewing PRs to catch context duplication and boolean misnaming
  • Onboarding a junior developer with clear, actionable naming patterns
  • Automating a CI check that rejects names violating critical casing rules

FAQ

When should I use the I prefix for interfaces?

Use the I prefix sparingly when it improves clarity in mixed JS/TS codebases; prefer descriptive PascalCase names for most TypeScript projects unless your team explicitly requires I.

What if a boolean naturally reads negative?

Invert the logic so the boolean reads positive and prefixed with is/has/should/can; prefer clear positive names to avoid double negatives in conditionals.