Code Style Guide

Personal code style preferences for TypeScript/React development.

Core Principles

• •Prefer the simplest viable solution; readability > cleverness
• •Add complexity only when clearly warranted (scale, correctness, security)
• •When uncertain, state assumptions and open questions instead of guessing

Output Format

• •Lead with the answer, then brief explanation
• •Match depth to complexity - don't over-explain simple things
• •For larger designs/refactors: summary → trade-offs → next steps

Code Style

Formatting (Prettier)

• •2-space indent
• •Single quotes (including JSX)
• •No semicolons
• •Named exports (not default exports)
• •Auto-organized imports (prettier-plugin-organize-imports)
• •Auto-sorted Tailwind classes (prettier-plugin-tailwindcss)

Naming Conventions

• •PascalCase: Components, Types, Interfaces
• •camelCase: Functions, variables, hooks
• •UPPER_SNAKE_CASE: Constants

TypeScript

• •Precise TS types; avoid any unless necessary (explain why)
• •Prefer ?? over || for nullish coalescing
• •Prefer explicit null checks over loose truthiness
• •Use strict mode
• •Consistent type imports: import { type Foo } (inline-type-imports)
• •Exhaustive switch statements (@typescript-eslint/switch-exhaustiveness-check)
• •Unused vars with underscore prefix allowed (_unused)

ESLint Rules (Enforced)

• •eqeqeq: smart - Use strict equality (except null checks)
• •no-console - Only console.warn and console.error allowed
• •consistent-type-imports - Inline type imports
• •switch-exhaustiveness-check - All switch cases must be handled
• •no-unused-vars - Underscore prefix (_) ignores args/vars
• •no-misused-promises - Except void return in JSX attributes

Code Organization

• •Inline until a pattern repeats 3+ times
• •For new components/hooks/APIs: include a usage example
• •Co-locate related code

React Patterns

• •Functional components only
• •Composition over configuration
• •Co-location of related code

State Management

• •Prefer derived/declarative state
• •Avoid useEffect unless truly needed for side effects or external sync
• •State progression: useState → Context → Zustand (when needed)

Hooks

• •Custom hooks start with use
• •Exhaustive deps (understand when to override)

Code Review

Severity Labels

• •critical: Must fix - security, data loss, crashes
• •major: Should fix - bugs, significant issues
• •minor: Nice to fix - style, minor improvements

Review Approach

• •Prefer minimal diffs
• •Flag unnecessary complexity with simpler alternative
• •Proactively flag security issues with brief explanation and fix
• •Note accessibility and SEO concerns when relevant

Stack-Specific

Next.js

• •App Router patterns
• •Proper server/client boundaries
• •Optimize for both SSR and CSR contexts

tRPC

• •Input validation with Zod
• •Proper error handling
• •Type-safe returns

TanStack Query

• •Meaningful query keys
• •Appropriate staleTime
• •Proper cache invalidation

AG Grid

• •Type-safe column definitions
• •Performance-conscious cell renderers
• •Proper SSRM implementation for large datasets