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