docs: Restructure AGENTS.md style guide with organized sections and code examples

pull/11252/head
Dax Raad 2026-02-01 22:28:00 -05:00
parent 8fbba8de73
commit eade8ee07b
1 changed files with 62 additions and 34 deletions

View File

@ -5,8 +5,9 @@
## Style Guide ## Style Guide
### General Principles
- Keep things in one function unless composable or reusable - Keep things in one function unless composable or reusable
- Avoid unnecessary destructuring. Instead of `const { a, b } = obj`, use `obj.a` and `obj.b` to preserve context
- Avoid `try`/`catch` where possible - Avoid `try`/`catch` where possible
- Avoid using the `any` type - Avoid using the `any` type
- Prefer single word variable names where possible - Prefer single word variable names where possible
@ -14,70 +15,97 @@
- Rely on type inference when possible; avoid explicit type annotations or interfaces unless necessary for exports or clarity - Rely on type inference when possible; avoid explicit type annotations or interfaces unless necessary for exports or clarity
- Prefer functional array methods (flatMap, filter, map) over for loops; use type guards on filter to maintain type inference downstream - Prefer functional array methods (flatMap, filter, map) over for loops; use type guards on filter to maintain type inference downstream
### Avoid let statements ### Naming
We don't like `let` statements, especially combined with if/else statements. Prefer single word names for variables and functions. Only use multiple words if necessary.
Prefer `const`.
Good:
```ts ```ts
const foo = condition ? 1 : 2 // Good
const foo = 1
function journal(dir: string) {}
// Bad
const fooBar = 1
function prepareJournal(dir: string) {}
``` ```
Bad: Reduce total variable count by inlining when a value is only used once.
```ts ```ts
let foo // Good
const journal = await Bun.file(path.join(dir, "journal.json")).json()
// Bad
const journalPath = path.join(dir, "journal.json")
const journal = await Bun.file(journalPath).json()
```
### Destructuring
Avoid unnecessary destructuring. Use dot notation to preserve context.
```ts
// Good
obj.a
obj.b
// Bad
const { a, b } = obj
```
### Variables
Prefer `const` over `let`. Use ternaries or early returns instead of reassignment.
```ts
// Good
const foo = condition ? 1 : 2
// Bad
let foo
if (condition) foo = 1 if (condition) foo = 1
else foo = 2 else foo = 2
``` ```
### Avoid else statements ### Control Flow
Prefer early returns or using an `iife` to avoid else statements. Avoid `else` statements. Prefer early returns.
Good:
```ts ```ts
// Good
function foo() { function foo() {
if (condition) return 1 if (condition) return 1
return 2 return 2
} }
```
Bad: // Bad
```ts
function foo() { function foo() {
if (condition) return 1 if (condition) return 1
else return 2 else return 2
} }
``` ```
### Prefer single word naming ### Schema Definitions (Drizzle)
Try your best to find a single word name for your variables, functions, etc. Use snake_case for field names so column names don't need to be redefined as strings.
Only use multiple words if you cannot.
Good:
```ts ```ts
const foo = 1 // Good
const bar = 2 const table = sqliteTable("session", {
const baz = 3 id: text().primaryKey(),
``` project_id: text().notNull(),
created_at: integer().notNull(),
})
Bad: // Bad
const table = sqliteTable("session", {
```ts id: text("id").primaryKey(),
const fooBar = 1 projectID: text("project_id").notNull(),
const barBaz = 2 createdAt: integer("created_at").notNull(),
const bazFoo = 3 })
``` ```
## Testing ## Testing
You MUST avoid using `mocks` as much as possible. - Avoid mocks as much as possible
Tests MUST test actual implementation, do not duplicate logic into a test. - Test actual implementation, do not duplicate logic into tests