domain-language-types
Name Types Using the Language of Your Problem Domain
Overview
Type names should communicate meaning, not structure.
A type named INodeNameValueData tells you nothing. A type named APIResponse or CustomerOrder tells you everything. Use the language of your business domain, not the language of data structures.
When to Use This Skill
- Naming new types
- Refactoring unclear type names
- Reviewing code with domain experts
- Designing public APIs
The Iron Rule
Type names should be meaningful to domain experts.
More from marius-townhouse/effective-typescript-skills
precise-any-variants
Use when forced to use any. Use when any is too broad. Use when function types need any.
86narrow-any-scope
Use when any is unavoidable. Use when working with untyped libraries. Use when silencing specific type errors.
35tsdoc-comments
Use when documenting public APIs. Use when writing library code. Use when using JSDoc-style comments. Use when generating documentation. Use when explaining complex types.
34exhaustiveness-checking
Use when handling tagged unions. Use when adding new cases to discriminated unions. Use when switch statements must cover all cases.
13code-gen-independent
Use when confused about types at runtime. Use when trying to use instanceof with interfaces. Use when type errors don't prevent JavaScript output.
12tsconfig-options
Use when setting up a TypeScript project. Use when confused by type checking behavior. Use when strict mode causes unexpected errors.
11