ts-style-review

TypeScript Style Guide Review

When reviewing TypeScript code, check against these sections. For full rules and examples, see google-ts-styleguide.md.

1. Source File Structure

• File order: copyright, @fileoverview, imports, implementation
• Use named exports only — no default exports
• Use ES6 modules — no namespace, no require()
• Prefer namespace imports for large APIs, named imports for frequently used symbols
• No mutable exports (export let) — use getter functions instead
• See google-ts-styleguide.md § 3. Source file structure

2. Variables & Literals

• const by default, let when reassigned, never var
• One variable per declaration
• Single quotes for strings, template literals for concatenation
• No Array() or Object() constructors
• See google-ts-styleguide.md § 4. Language features

3. Classes

• Use readonly for properties never reassigned after constructor
• Use parameter properties (constructor(private readonly foo: Foo))
• No public keyword — TypeScript is public by default
• No #private fields — use private modifier
• No prototype manipulation
• See google-ts-styleguide.md § 4. Classes

4. Functions

• Prefer function declarations for named functions
• Arrow functions for callbacks and nested functions — never function expressions
• Use rest parameters, not arguments
• Use spread syntax, not Function.prototype.apply
• See google-ts-styleguide.md § 4. Functions

5. Control Flow & Error Handling

• Always use braces for control flow blocks
• Always === and !== (exception: == null for null/undefined check)
• for...of for arrays, never for...in
• Only throw Error instances (or subclasses), never strings
• All switch must have default, no fall-through
• See google-ts-styleguide.md § 4. Control structures

6. Naming

• UpperCamelCase: classes, interfaces, types, enums, decorators, TSX components
• lowerCamelCase: variables, parameters, functions, methods, properties
• CONSTANT_CASE: global constants, enum values
• Descriptive names — no ambiguous abbreviations
• Treat acronyms as words (loadHttpUrl, not loadHTTPURL)
• See google-ts-styleguide.md § 5. Naming

7. Type System

• Prefer interface over type alias for object shapes
• Use unknown over any — narrow with type guards
• Use optional (?) over | undefined
• T[] for simple types, Array<T> for complex
• No wrapper types (String, Boolean, Number) — use primitives
• No @ts-ignore or @ts-nocheck
• See google-ts-styleguide.md § 6. Type system

8. Schema & Type Definitions (Team Convention)

• Use Zod for defining schemas, then derive TypeScript types with z.infer<typeof schema>
• If types are not shared across files, define the Zod schema and inferred type at the top of the same file that uses them
• If types are shared, place them in a shared types/schemas module
• Example:

  import { z } from 'zod';
  
  const UserSchema = z.object({
    id: z.string(),
    name: z.string(),
    email: z.string().email(),
  });
  
  type User = z.infer<typeof UserSchema>;
  

9. Comments & Documentation

• /** JSDoc */ for public API documentation
• // for implementation comments
• No type annotations in JSDoc — TypeScript handles types
• Mark deprecated code with @deprecated
• See google-ts-styleguide.md § 8. Comments and documentation