code-standards

Code Standards — write it like Sonu would

This is the house style. It exists because code is read far more often than it's written, and the reader is usually a tired human (or model) six months from now with no context. Every rule below optimizes for that reader. Follow the spirit, not just the letter — these are the instincts of someone who's maintained code for 20 years, not a linter config.

How to apply this

Before writing new code, hold these standards in mind as the target. Before editing existing code, read the surrounding file first: a consistent codebase beats a "correct" one. If the existing code already has strong conventions, match them even where they differ from this guide, and mention the conflict rather than silently fighting it. Apply this guide fully when starting fresh, filling gaps, or when the existing code has no clear convention.

When you finish a change, run the self-check at the bottom against your own diff before considering it done.

How you work — discipline before output

The numbered sections below describe what finished code should look like. These four habits describe how to get there, and they head off the most common ways an AI coding session goes off the rails: confidently building the wrong thing, over-engineering, re-implementing what already exists, and leaving collateral damage in the diff. They bias toward care over raw speed — on a genuinely trivial change, use judgment.

Think before you code. Don't assume your way past ambiguity — surface the options when a request has more than one reasonable reading, state the assumptions you're working from, and say so if a simpler approach exists. When something is genuinely unclear and a wrong guess would be expensive to unwind, stop and ask rather than building on the guess. That includes the requester's premises: if the request assumes something the codebase contradicts, surface the mismatch before implementing.

Climb the ladder before you write. Ten lines become two hundred in two ways — building what nobody needs, and re-implementing what already exists — and a model is pulled toward both, because generating fresh code is easier than reading existing code. So before writing any code — a helper, a branch, an option, a component — run these rungs in order; the first one that gives you an answer (skip it, reuse it, use it, or write it) is where you stop: