Quality & Team

Coding Standards & Style

Foundational

Code is read far more often than it is written, usually by someone other than you, months later. Consistent style and clear naming keep a shared codebase readable as it grows. The goal is not personal taste. It is that any of us can open any file and understand it quickly. Let tools handle the mechanical parts, so reviews focus on what matters.

Standards do two jobs. They end pointless debate (where braces go, tabs versus spaces) by deciding it once and automating it. And they make code predictable, so it is faster to read and safer to change. For a team with many junior engineers, consistency matters even more. It lowers the cost of moving between parts of the codebase and learning from each other.

The most important standard is naming. Names that say what something is and does are the cheapest, most effective documentation there is. After that, let formatters and analysers handle style automatically, so people spend review time on correctness and design, not commas.

Write readable code

DoName things clearly and honestly. Variables, methods, and types should say what they are and do. Prefer a longer clear name over a short cryptic one.
DoFollow the language's idioms and the codebase's existing conventions. Match the surrounding code rather than adding a personal style.
DoKeep functions and classes small and focused on one job, using early returns instead of deep nesting, so the logic is easy to follow (see Separation of Concerns).
DoMake the code explain itself. Use comments for the why and the non-obvious, not to repeat what the code says (see Documentation as Code).
ConsiderLeaving each file a little clearer than you found it as you work.

Cryptic and dense var d = c.Where(x => x.s == 1 && x.t == tid).ToList(); // what is any of this?

Single-letter names and magic numbers force the next reader (or you, in three months) to decode it. Unreadable code is slow to change and easy to break.

Names that explain themselves

var activeCustomers = customers
  .Where(c => c.Status == Status.Active && c.TenantId == tenantId)
  .ToList();

The intent is clear at a glance. No decoding, no guessing what 1 meant. The code documents itself.

Let tools do the mechanical work

DoAutomate formatting and linting (for example .editorconfig, analysers, Prettier/ESLint) and run them in the pipeline, so style stays consistent and is never argued in review (see CI/CD & Deployment).
DoTurn on and act on the compiler and analyser warnings and nullable reference types. They catch real bugs, not just style (see C# / .NET gotchas).
ConsiderTreating analyser warnings as errors in the build for the rules that matter, so they cannot quietly build up.
AvoidDebating formatting by hand in code review. If it can be automated, automate it and move on (see Code Review).
AvoidClever, dense code that is hard to read for a small gain. Clarity beats cleverness in a shared codebase.

Self-review checklist

AskWould someone new to this code understand it quickly, without me explaining?
AskDo my names say what things actually are and do?
AskDoes this match the conventions of the surrounding code?
AskAm I leaving anything for review that a formatter or analyser should handle automatically?

Why it matters: A consistent, readable codebase is faster and safer to change, easier to join, and less likely to hide bugs in confusing code. That matters most for a growing, mostly-junior team sharing one system. Automating style frees human attention for the things that really need judgement.