Naming conventions consistent

Inconsistent naming conventions in TypeScript code — snake_case variables, Hungarian notation, mixed component casing — increase cognitive load for every developer reading the code and signal that the project lacks enforced standards. ISO 25010:2011 §6.5.2 classifies this as a readability and maintainability defect. In practice, mixed conventions also correlate with inconsistent module structure, inconsistent error handling, and higher defect rates: they are a proxy signal for how rigorously the codebase enforces its own standards.

Define a convention and enforce it with ESLint's @typescript-eslint/naming-convention rule so violations are caught automatically:

{
  "rules": {
    "@typescript-eslint/naming-convention": [
      "error",
      { "selector": "variable", "format": ["camelCase", "UPPER_CASE"] },
      { "selector": "function", "format": ["camelCase", "PascalCase"] },
      { "selector": "typeLike", "format": ["PascalCase"] },
      { "selector": "interface", "format": ["PascalCase"] }
    ]
  }
}

For existing violations, use eslint --fix for auto-fixable cases. Snake_case variables in TypeScript code (user_id, is_valid) are the most common — run a search-replace pass on the highest-traffic files first.

• ID: code-quality-essentials.organization.naming-conventions

• Severity: low

• What to look for: Sample 20-30 files from src/, app/, and lib/. Check: variable and function names are camelCase (getUserById, isAuthenticated, maxRetries); class names and React components are PascalCase (UserService, AuthButton, DashboardPage); type and interface names are PascalCase (UserProfile, ApiResponse); constants are either camelCase or UPPER_SNAKE_CASE — pick one and stick to it. Flag mixed conventions: snake_case variables in TypeScript code (user_id, is_valid), Hungarian notation (strUsername, bIsActive), inconsistent component naming (some PascalCase, some kebab-case component files). File naming conventions also matter: Next.js uses kebab-case files, React components may use PascalCase files — check for consistency within the project's own pattern.

• Pass criteria: Enumerate all relevant code locations. Consistent naming convention throughout the codebase matching standard TypeScript/JavaScript conventions for each identifier type with at least 1 verified location.

• Fail criteria: Mixed naming conventions — e.g., snake_case variable names in TypeScript code, inconsistent component casing, Hungarian notation.

• Skip (N/A) when: Never — naming conventions apply to all codebases.

• Detail on fail: "Mixed naming conventions: snake_case variable names found in TypeScript source; constants use both camelCase and UPPER_SNAKE_CASE"

• Remediation: Define a convention and apply it with ESLint's @typescript-eslint/naming-convention rule:

  {
    "rules": {
      "@typescript-eslint/naming-convention": [
        "error",
        { "selector": "variable", "format": ["camelCase", "UPPER_CASE"] },
        { "selector": "function", "format": ["camelCase", "PascalCase"] },
        { "selector": "typeLike", "format": ["PascalCase"] },
        { "selector": "interface", "format": ["PascalCase"] }
      ]
    }
  }
  

  Use search/replace to migrate existing violations, or apply eslint --fix for auto-fixable cases.