the-art-of-naming_skill

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

JavaScript

16

GitHub Stars

3

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

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

AGENTS.md26.2 KB
metadata.json595 B
SKILL.md3.8 KB

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

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.