Variable and Function Naming Rules
Variable naming: AI rule: 'Variables use camelCase. Boolean variables: prefix with is, has, can, should (isActive, hasPermission, canEdit, shouldRefresh). Arrays: plural nouns (users, notifications, orderItems). Single items: singular nouns (user, notification, orderItem). Counts: suffix with Count (userCount, notificationCount). Maps/Records: suffix with Map or By (userMap, notificationById). Constants: UPPER_SNAKE_CASE for true constants (MAX_RETRIES, API_BASE_URL), camelCase for derived values (defaultTimeout = MAX_RETRIES * 1000).' The AI: generates self-documenting variable names.
Function naming: AI rule: 'Functions use camelCase with verb-first naming. CRUD operations: getUser, createUser, updateUser, deleteUser. Transformations: formatDate, parseAmount, normalizeEmail. Validation: validateEmail, isValidPassword, assertAuthorized. Event handlers: handleClick, onSubmit, handleNotificationDismiss. Async functions: no special prefix (getUser, not fetchUser or asyncGetUser — the return type communicates async). Factory functions: createUserService, buildQueryOptions.' The AI: generates function names that communicate their purpose and behavior.
Acronym handling: AI rule: 'Acronyms in names: treat as a single word with only the first letter capitalized. userId (not userID), apiUrl (not apiURL), htmlParser (not HTMLParser). Exception: two-letter acronyms keep both uppercase (IO, DB) but only at the start of a name: dbConnection, ioStream. In PascalCase contexts (types, classes): ApiClient, HtmlParser, UserId.' The AI: handles acronyms consistently — the most common naming inconsistency in AI-generated code. AI rule: 'Variable and function naming rules are the highest-impact naming rules because they affect every line of code. One rule about boolean prefixes: applies to every boolean in the project. One rule about verb-first functions: applies to every function. The coverage: total.'
Component and Type Naming Rules
React/Vue component naming: AI rule: 'Components use PascalCase. Component names: descriptive nouns or noun phrases (UserProfile, NotificationList, PaymentForm). Compound components: Parent.Child pattern (Dialog.Header, Dialog.Body, Dialog.Footer) or hyphenated context (UserProfile, UserProfileAvatar, UserProfileSettings). Layout components: suffix with Layout (DashboardLayout, AuthLayout). Page components: suffix with Page (SettingsPage, ProfilePage). No generic names (Component, Container, Wrapper) without a qualifying prefix.' The AI: generates component names that describe their role in the UI.
TypeScript type naming: AI rule: 'Types and interfaces: PascalCase nouns. Data types: describe the entity (User, Notification, PaymentIntent). Props types: suffix with Props (ButtonProps, UserProfileProps). Response types: suffix with Response (LoginResponse, OrderListResponse). Request types: suffix with Request (CreateUserRequest, UpdateOrderRequest). Enum types: singular PascalCase (UserRole, NotificationChannel, PaymentStatus). Enum values: PascalCase (UserRole.Admin, UserRole.Member) or UPPER_SNAKE_CASE (UserRole.ADMIN) — pick one, be consistent.' The AI: generates type names that communicate their purpose and usage context.
Generic type parameter naming: AI rule: 'Single-letter generics only for truly generic code: T for type, K for key, V for value, E for error. For domain-specific generics: use descriptive names (TEntity, TResponse, TPayload). Never use single-letter names when the generic has a specific meaning: Result<Data, AppError> not Result<T, E>.' The AI: generates readable generic types. AI rule: 'Component and type naming rules create a searchable codebase. When every props type is [Component]Props, every response type is [Entity]Response, and every page is [Name]Page: developers find any type by typing the pattern. The naming convention: becomes a search shortcut.'
Developer needs the type for the notification list API response. Without naming rules: is it NotificationData? NotificationResult? NotificationPayload? NotificationOutput? Four possible names. Developer: searches the codebase. With naming rules (suffix with Response): NotificationListResponse. One possible name. Developer: types it directly. The suffix convention: turns type naming into a formula. [Entity][Context][Suffix]. UserProfileProps. CreateOrderRequest. LoginResponse. Every type: predictable, findable, no searching required.
File and Database Naming Rules
File naming: AI rule: 'Source files: kebab-case for multi-word names (user-profile.tsx, notification-service.ts). Component files: match the component name in PascalCase (UserProfile.tsx) OR kebab-case (user-profile.tsx) — choose one, be consistent. Test files: same name with .test suffix (user-profile.test.ts). Type files: same name with .types suffix (user-profile.types.ts). Index files: only for re-exports, never for implementation. File name: must describe the primary export.' The AI: generates files with names that match their contents.
Database naming: AI rule: 'Tables: plural snake_case nouns (users, notifications, order_items). Columns: singular snake_case (email, created_at, notification_count). Primary keys: id (not user_id in the users table). Foreign keys: referenced_table_id (user_id in orders table references users.id). Indexes: idx_table_column (idx_users_email). Timestamps: created_at, updated_at (not createdAt — database conventions differ from code conventions). Enums: singular snake_case (user_role, payment_status).' The AI: generates database schemas with consistent naming that distinguishes database conventions from application code conventions.
API naming: AI rule: 'REST endpoints: plural nouns, kebab-case. GET /api/users, GET /api/users/:id, POST /api/users, PUT /api/users/:id, DELETE /api/users/:id. Nested resources: /api/users/:userId/notifications. Query parameters: camelCase (pageSize, sortBy, filterStatus). Response fields: camelCase (matching TypeScript conventions). Action endpoints (non-CRUD): POST /api/users/:id/activate, POST /api/orders/:id/refund.' The AI: generates API endpoints that follow RESTful naming conventions consistently. AI rule: 'File, database, and API naming rules handle the context-switching problem. Code uses camelCase. Database uses snake_case. URLs use kebab-case. Each context has its own convention. The AI: applies the correct convention for each context because the rules specify them separately.'
New developers often ask: 'Should it be created_at or createdAt?' The answer: both. Database columns: created_at (snake_case — the database convention). Application code: createdAt (camelCase — the TypeScript convention). The ORM: handles the mapping automatically. AI rule: 'Database uses snake_case. Application code uses camelCase. The ORM maps between them.' Without this rule: the AI sometimes uses camelCase in database schemas or snake_case in TypeScript code. Both are wrong — in their context. The rule: clarifies which convention applies where.
Naming Anti-Patterns the AI Should Avoid
Anti-pattern 1: Hungarian notation and type prefixes. AI rule: 'Never prefix variable names with type indicators. No strName, intCount, arrUsers, boolIsActive. The type system provides this information. Exception: interface prefixes (IUserService) — only if the project already uses this convention. Never introduce I-prefix in a project that does not use it.' The AI: avoids type-in-name patterns that add noise without value.
Anti-pattern 2: Abbreviations and acronyms. AI rule: 'No abbreviations in names. Use notification not notif, configuration not config, repository not repo, application not app. Exceptions: well-known abbreviations that are clearer than the full word (id, url, api, html, css, db). The test: if the abbreviation requires explanation, use the full word.' The AI: generates readable names. The reviewer: never asks 'what does notifSvc mean?' because the AI writes notificationService.
Anti-pattern 3: Context duplication. AI rule: 'Do not repeat the containing context in member names. In a User type: use email not userEmail, name not userName (the User context is already provided by the type). In a NotificationService: use send not sendNotification (the Notification context is already provided by the service name). Exception: when the member name would be ambiguous without context (User.id is fine, but in a join query: user.id vs order.id requires the prefix).' The AI: generates concise names that leverage their containing context. AI rule: 'Naming anti-patterns are the rules the AI needs most because its training data contains all patterns — good and bad. Without rules: the AI may generate strName in one function and name in the next. With anti-pattern rules: the AI consistently avoids the patterns you have prohibited. Negative rules are as important as positive rules.'
User type with a userEmail field. The word 'user' appears twice: once in the type name, once in the field name. When accessing: user.userEmail — redundant. Better: user.email — the User context is already provided by the variable name. The AI: often generates context-duplicated names because its training data contains both patterns. AI rule: 'Do not repeat containing context in member names.' Result: user.email not user.userEmail. notificationService.send not notificationService.sendNotification. The code: 30% more concise, equally clear.
Naming Conventions Quick Reference
Quick reference for AI coding naming conventions.
- Variables: camelCase, booleans with is/has/can prefix, arrays plural, counts with Count suffix
- Functions: camelCase, verb-first (get/create/update/delete/format/validate/handle)
- Acronyms: first letter only capitalized (userId, apiUrl) except two-letter (IO, DB)
- Components: PascalCase nouns, Layout/Page suffixes, no generic names without qualifier
- Types: PascalCase, Props/Response/Request suffixes, descriptive generic parameters
- Files: kebab-case or PascalCase (pick one), .test/.types suffixes, no implementation in index files
- Database: snake_case tables (plural), snake_case columns (singular), created_at timestamps
- API: plural kebab-case routes, camelCase query params, POST for non-CRUD actions
- Anti-patterns: no Hungarian notation, no abbreviations, no context duplication in member names