Best-practice naming conventions for TypeScript via ESLint.
Documentation • Install • Usage • Rule overview
--- ## Why Naming conventions in software development offer numerous benefits: - **Readability**: Consistent naming makes code easier to read and understand, reducing cognitive load when scanning files. - **Maintainability**: Enforces best practices, improving code quality and consistency across the codebase. - **Code Review and Collaboration**: Eliminates debates on naming styles, allowing reviewers to focus on logic and speeding up the process. - **Code Uniformity**: Uniform naming promotes collective code ownership, as code looks the same regardless of who wrote it. - **Aesthetics**: Provides functional benefits and aesthetic appeal, with a visually pleasing and harmonious structure. This config makes naming **predictable** and **review-friendly** by enforcing a coherent set of rules that scale well across: - Apps and Libraries - Frontend and Backend - Monorepos and Multi-team codebases It is intentionally **BYO parser setup** — it ships rules only and does not assume your repo layout or `parserOptions.project`. --- ## Documentation Comprehensive documentation with detailed rule explanations and examples is available at **[drsmile444.github.io/eslint-config-naming](https://drsmile444.github.io/eslint-config-naming/)**. Key resources: - **[Getting Started Guide](https://drsmile444.github.io/eslint-config-naming/getting-started)** — Installation and configuration - **[Rule Matrix](https://drsmile444.github.io/eslint-config-naming/rules/)** — Complete rule matrix with examples - **[Changelog](https://drsmile444.github.io/eslint-config-naming/reference/changelog)** — Version history and updates --- ## At a Glance This configuration enforces consistent naming patterns across TypeScript constructs: | Category | Enforced Style | Example | | ----------------------------- | ----------------------------------------------- | ---------------------------------- | | **Types** | PascalCase, no `I`/`T` prefixes | `ApiResponse`, `UserData` | | **Classes** | PascalCase | `HttpClient`, `DataService` | | **Interfaces** | PascalCase | `Config`, `Options` | | **Enums** | PascalCase (name), UPPER_CASE (members) | `enum Status { ACTIVE, INACTIVE }` | | **Variables** | camelCase or UPPER_CASE | `userName`, `MAX_RETRIES` | | **Booleans** | Prefixed with `is\|should\|has\|can\|did\|will` | `isValid`, `hasAccess` | | **Functions** | camelCase | `calculateTotal()`, `fetchData()` | | **Class Members (public)** | camelCase or snake_case | `userCount`, `api_key` | | **Class Members (protected)** | camelCase (no underscore) | `internalState` | | **Generic Types** | Single letter or T-prefixed | `T`, `TData`, `TKey` | **Abbreviations and single-letter variables are restricted** — only `x`, `y`, `z` are allowed for coordinates. Descriptive names like `errorMessage` and `index` are enforced over vague shortcuts like `err`, `str`, or `i`. ### Code Examples| ❌ Incorrect | ✅ Correct |
|---|---|
|
```ts
// Type prefixes
interface IApiResponse {}
type TUserData = {};
// Wrong casing
enum status {
active,
inactive,
}
class userService {}
// Variables
const Myvariable = 'value';
const my_constant = 'constant';
const ready = true;
// Abbreviations
const str = 'message';
// Generics
type Cache |
```ts
// Clean type names
interface ApiResponse {}
type UserData = {};
// Proper casing
enum Status {
ACTIVE,
INACTIVE,
}
class UserService {}
// Variables
const myVariable = 'value';
const MY_CONSTANT = 'constant';
const isReady = true;
// Descriptive names
const message = 'message';
// Proper generics
type Cache |