evilissimo/naming-things
Reviews and improves **names** in code — variables, functions, classes, modules, parameters — for clarity, intent, and consistency with language/team conventions. Triggers when asked to review names, rename things, improve code readability, clean up confusing code, or when examining code with generic/vague names like "data", "info", "manager", "temp", "util". Does NOT trigger for general code review unrelated to naming, architecture design, debugging, or performance optimization. Identifies naming anti-patterns (generic names, misleading names, type-encoding, abbreviations), suggests role-based names that reveal intent, checks consistency with project/domain vocabulary, and flags misalignment with language culture.
91
90%
Does it follow best practices?
Impact
94%
1.05xAverage score across 5 eval scenarios
Passed
No known issues
typescript.mdreferences/
TypeScript / JavaScript Naming Conventions
Based on common conventions in the TypeScript/JavaScript ecosystem.
Convention Table
| Thing | Convention | Example |
|---|---|---|
| Variable | camelCase | userName, totalCount |
| Function | camelCase | calculateTotal(), getUser() |
| Class | PascalCase | CustomerOrder, HttpClient |
| Interface | PascalCase (no I prefix) | UserProps, OrderConfig |
| Type | PascalCase | PaymentStatus, JsonValue |
| Enum | PascalCase (members: PascalCase) | enum Color { Red, Green, Blue } |
| Module / file | camelCase or kebab-case | orderService.ts, user-utils.ts |
| Constant (module-level) | SCREAMING_SNAKE_CASE or camelCase | MAX_RETRY_COUNT |
| React component | PascalCase | UserProfile, OrderList |
| React hook | camelCase, prefix use | useUser(), useFetch() |
| Private | Prefix # or _ (convention) | #privateField, _internal |
| Boolean prop | Prefix is, has, should | isActive, hasError, shouldShow |
Key Points
- No
Iprefix on interfaces — modern TypeScript convention is justPascalCase:UserData, notIUserData - React component names are always PascalCase — lowercase elements are treated as HTML tags by JSX
- Event handlers use
onorhandleprefix:onSubmit,handleClick,onChange - Boolean variables and props use
is/has/can/should:isLoading,hasPermission,canSubmit - Avoid abbreviations unless universally known:
btn→button,cfg→config,msg→message - Async functions don't need special naming — the
asynckeyword already signals this - Factory functions use
createprefix:createClient(),createStore() - Array variables often plural:
users,orders,items
TypeScript-Specific
- Type parameters (generics) typically single uppercase:
<T>,<K>,<V>, or descriptive:<TEntity> - Discriminated unions use descriptive literal type names:
type Status = "idle" | "loading" | "success" | "error" - Utility types use
Tprefix for internal helpers, but prefer descriptive names for public APIs
Common Offenses
| Bad | Good | Reason |
|---|---|---|
data | userData, responseData, orders | Generic — what data? |
info | userInfo, orderInfo, errorDetails | Vague — info about what? |
x (outside math) | result, value, item | Loses meaning |
IIndexable | Indexable | I prefix is legacy |
process() | processPayment(), processOrder() | Too vague |
handle() | handleClick(), handleSubmit() | Handle what? |
thing / stuff | Name it for what it is | Never acceptable |