Compare commits
3 Commits
d83bd08d4d
...
59999115b1
| Author | SHA1 | Date | |
|---|---|---|---|
| 59999115b1 | |||
|
|
f05fdf6674 | ||
|
|
2b674c7d22 |
@@ -136,8 +136,15 @@ last_modified: 2026-02-22
|
|||||||
1. Provide a .gitignore file that ignores at least `*.log`, `*.out`, and
|
1. Provide a .gitignore file that ignores at least `*.log`, `*.out`, and
|
||||||
`*.test` files, as well as any binaries.
|
`*.test` files, as well as any binaries.
|
||||||
|
|
||||||
1. Constructors should be called `New()` whenever possible. `modulename.New()`
|
1. Constructors **must** be called `New()`. `modulename.New()` works great if
|
||||||
works great if you name the packages properly.
|
you name the packages properly. If the constructor creates an instance from
|
||||||
|
an existing value or representation, `From<Something>()` (e.g. `FromBytes()`,
|
||||||
|
`FromConfig()`) is also acceptable. If the package contains multiple types
|
||||||
|
and `New()` is ambiguous, `NewThing()` is occasionally acceptable — but
|
||||||
|
prefer restructuring packages so each type gets its own package and a plain
|
||||||
|
`New()`. Do not invent creative constructor names like `Create()`, `Make()`,
|
||||||
|
`Build()`, `Open()` (unless wrapping an OS resource), or `Init()`. If you
|
||||||
|
see a constructor with a non-standard name, rename it.
|
||||||
|
|
||||||
1. Don't make packages too big. Break them up.
|
1. Don't make packages too big. Break them up.
|
||||||
|
|
||||||
@@ -149,9 +156,15 @@ last_modified: 2026-02-22
|
|||||||
1. Use descriptive names for modules and filenames. Avoid generic names like
|
1. Use descriptive names for modules and filenames. Avoid generic names like
|
||||||
`server`. `util` is banned.
|
`server`. `util` is banned.
|
||||||
|
|
||||||
1. Constructors should take a Params struct if they need more than 1-2
|
1. Constructors **must** take a `Params` struct (or `ThingParams` when
|
||||||
arguments. Positional arguments are an endless source of bugs and should be
|
`NewThing()` is used), even for a single argument. Named fields in a Params
|
||||||
avoided whenever possible.
|
struct are always clearer than positional arguments. Positional arguments
|
||||||
|
for constructors are an endless source of bugs — they make call sites
|
||||||
|
unreadable, invite wrong-order errors that the compiler can't catch when
|
||||||
|
types coincide, and force every caller to update when a new field is added.
|
||||||
|
The only exception is when the single argument is stupidly obvious from
|
||||||
|
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
|
||||||
|
|||||||
Reference in New Issue
Block a user