style: strengthen constructor naming and Params struct rules #19

Merged
sneak merged 4 commits from style/constructor-naming-params into main 2026-03-20 07:06:03 +01:00
Showing only changes of commit 4c643d1aa2 - Show all commits

View File

@@ -157,13 +157,14 @@ last_modified: 2026-02-22
`server`. `util` is banned. `server`. `util` is banned.
1. Constructors **must** take a `Params` struct (or `ThingParams` when 1. Constructors **must** take a `Params` struct (or `ThingParams` when
`NewThing()` is used). Positional arguments for constructors are an endless `NewThing()` is used), even for a single argument. Named fields in a Params
source of bugs — they make call sites unreadable, invite wrong-order errors struct are always clearer than positional arguments. Positional arguments
that the compiler can't catch when types coincide, and force every caller to for constructors are an endless source of bugs — they make call sites
update when a new field is added. The only exception is a constructor that unreadable, invite wrong-order errors that the compiler can't catch when
takes exactly one argument whose meaning is obvious from context (e.g. types coincide, and force every caller to update when a new field is added.
`New(ctx)` or `FromBytes(b)`). Two or more arguments → use a Params struct, The only exception is when the single argument is stupidly obvious from
no exceptions. context — e.g. `featureflag.New(true)` or `thing.NewFromReader(r)`. When in
doubt, use a Params struct.
1. Use `context.Context` for all functions that need it. If you don't need it, 1. Use `context.Context` for all functions that need it. If you don't need it,
you can pass `context.Background()`. Anything long-running should get and you can pass `context.Background()`. Anything long-running should get and