Programming Languages
This section covers per-language naming and code conventions. Each page is the single place for one language’s whole ecosystem: the TypeScript page covers TS/Node plus React/TanStack and Astro, and the Go page covers Go plus Fiber services.
The general file-naming and casing rules that apply across every language live here. When you are naming a symbol inside code, open the language page and copy the pattern.
Our approach
Names should be predictable: a developer who knows what a thing is should be able to guess its name before searching for it. That means using the convention native to the language and the framework so symbols read the same way in search, code review, generated docs, and stack traces.
When in doubt, match the local convention of the file you are editing before introducing a new pattern. Favor complete names over abbreviations, name for purpose and behavior, and keep machine-read names stable once automation or downstream consumers depend on them.
Baseline rules
These rules apply to every language in the stack, so that a symbol’s purpose is guessable even when switching between the TypeScript and Go parts of the same system.
| Context | Convention | Example |
|---|---|---|
| Length | Favor complete names over abbreviations | formatCurrency not fmtCcy |
| Intent | Name for purpose and behavior | EmailSender not Helper |
| Single letters | Avoid except loop indices or math | for i := range xs |
| Local convention | Match the local convention before introducing a new one | follow the file you are editing |
| Stability | Keep names stable once used by automation or downstream consumers | don’t rename live infrastructure casually |
| Abbreviations | Avoid clever abbreviations unless already the domain term | spell it out |
File naming
Use file names that make ownership and test coverage obvious without opening the file. Prefer domain names over generic ones, and keep implementation and test files aligned.
Casing by language
| Language | Filename convention | Example |
|---|---|---|
| TypeScript | kebab-case | user-create-dialog.tsx |
| Go | snake_case | user_handler.go |
Components and symbols
PascalCase is the cross-language convention for component symbols (React and Astro components), even though the files that hold them are kebab-case. See each language page for the full symbol-casing table.
Tests and stories
- Test files mirror the implementation name:
foo.tsx/foo.test.tsx, because that pairing makes coverage visible at a glance in a file tree without opening either file. - Story files use
<component-name>.stories.tsxnaming.
Placement
- Prefer colocated component folders with clear domain boundaries.
- Avoid index barrel files where direct names improve grep and searchability.
- Keep generated or test-fixture artifacts in dedicated subfolders so intent stays visible.
- For build artifacts, keep generated files in clearly scoped folders and exclude them from primary domain naming decisions.
Examples
The table below illustrates the most common naming decisions across TypeScript and Go — pairing correct and incorrect forms so the distinction is concrete rather than abstract.
| ✓ Do | ✗ Don’t |
|---|---|
user-create-dialog.tsx | UserCreateDialog.tsx |
user-create-dialog.test.tsx | dialog.test.tsx |
user_handler.go | userHandler.go |
fixtures/users/active-user.json | data2.json |
Where it’s enforced
File-name casing is enforced per language. TypeScript filenames are checked by the ESLint / Biome configuration shared across TS repos (see the TypeScript page → “Where it’s enforced”). Go filenames and symbol casing are enforced by golangci-lint via .golangci.yml (see the Go page → “Where it’s enforced”).
Language → page
| Language | Page |
|---|---|
| TypeScript (TS/Node, React/TanStack, Astro) | TypeScript |
| Go (Go, Fiber services) | Go |