Skip to content
Workspace
Contact
Status
Owner
Tags

These are the conventions reviewers look for. They exist to make code easy to read six months from now, not to win arguments.

TypeScript

  • Strict mode everywhere. No any without a comment explaining why.
  • Prefer discriminated unions over optional flags.
  • Validate at the edges with zod, then trust the types inside.
load-state.tsts
1type LoadState<T> =
2  | { status: "idle" }
3  | { status: "loading" }
4  | { status: "error"; error: string }
5  | { status: "ready"; data: T }
6
7export function describe(state: LoadState<Invoice[]>) {
8  switch (state.status) {
9    case "ready":
10      return `${state.data.length} invoices`
11    case "error":
12      return state.error
13    default:
14      return "Loading…"
15  }
16}

React

  • Server components by default; "use client" only where state lives
  • Derive state instead of syncing it with effects
  • Every icon-only button has an aria-label
  • Lists over 200 rows are virtualised

Pull requests

  1. Keep PRs under roughly 400 changed lines; split refactors from features.
  2. Write the description for someone who has not read the ticket.
  3. Add screenshots or a short recording for any UI change.
Code is read far more often than it is written. Optimise for the reviewer.
Team principle

Pages inside

Linked mentions1

Comments

V