3 Commits

Author SHA1 Message Date
59999115b1 Merge branch 'main' into style/constructor-naming-params
Some checks failed
check / check (push) Failing after 7s
2026-03-18 04:00:44 +01:00
user
f05fdf6674 style: Params struct required even for single arguments
Some checks failed
check / check (push) Failing after 6s
Only exception: stupidly obvious single args (featureflag.New(true)).
When in doubt, use Params.
2026-03-17 19:57:28 -07:00
user
2b674c7d22 style: strengthen constructor naming and Params struct rules
Some checks failed
check / check (push) Failing after 7s
- Constructors must be New(), From<Something>(), or NewThing() (multi-type pkg)
- Strongly discourage creative names (Create, Make, Build, Init)
- Constructors must use Params struct for 2+ arguments, no exceptions
- Single obvious argument (ctx, bytes) is the only exception
2026-03-17 19:53:45 -07:00
2 changed files with 9 additions and 45 deletions

View File

@@ -1,6 +1,6 @@
--- ---
title: Code Styleguide — Go title: Code Styleguide — Go
last_modified: 2026-03-18 last_modified: 2026-02-22
--- ---
1. Try to hard wrap long lines at 77 characters or less. 1. Try to hard wrap long lines at 77 characters or less.
@@ -138,13 +138,13 @@ last_modified: 2026-03-18
1. Constructors **must** be called `New()`. `modulename.New()` works great if 1. Constructors **must** be called `New()`. `modulename.New()` works great if
you name the packages properly. If the constructor creates an instance from you name the packages properly. If the constructor creates an instance from
an existing value or representation, `From<Something>()` (e.g. an existing value or representation, `From<Something>()` (e.g. `FromBytes()`,
`FromBytes()`, `FromConfig()`) is also acceptable. If the package contains `FromConfig()`) is also acceptable. If the package contains multiple types
multiple types and `New()` is ambiguous, `NewThing()` is occasionally and `New()` is ambiguous, `NewThing()` is occasionally acceptable — but
acceptable — but prefer restructuring packages so each type gets its own prefer restructuring packages so each type gets its own package and a plain
package and a plain `New()`. Do not invent creative constructor names like `New()`. Do not invent creative constructor names like `Create()`, `Make()`,
`Create()`, `Make()`, `Build()`, `Open()` (unless wrapping an OS resource), `Build()`, `Open()` (unless wrapping an OS resource), or `Init()`. If you
or `Init()`. If you see a constructor with a non-standard name, rename it. 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.

View File

@@ -1,6 +1,6 @@
--- ---
title: Repository Policies title: Repository Policies
last_modified: 2026-03-18 last_modified: 2026-03-12
--- ---
This document covers repository structure, tooling, and workflow standards. Code This document covers repository structure, tooling, and workflow standards. Code
@@ -149,42 +149,6 @@ style conventions are in separate documents:
- `make test` must complete in under 20 seconds. Add a 30-second timeout in the - `make test` must complete in under 20 seconds. Add a 30-second timeout in the
Makefile. Makefile.
- **`make test` should use the conditional verbose rerun pattern.** Run tests
without `-v` (verbose) first. If tests fail, automatically rerun with `-v` to
show full output. This keeps CI logs and `docker build` output clean on
success (just package/suite summaries) while providing full diagnostic detail
on failure (every test case, every assertion). The general shell pattern:
```makefile
test:
@<test-command> || \
{ echo "--- Rerunning with -v for details ---"; \
<test-command-with-v>; exit 1; }
```
Go example:
```makefile
test:
@go test -timeout 30s -race -cover ./... || \
{ echo "--- Rerunning with -v for details ---"; \
go test -timeout 30s -race -v ./...; exit 1; }
```
Python example:
```makefile
test:
@python -m pytest || \
{ echo "--- Rerunning with -v for details ---"; \
python -m pytest -v; exit 1; }
```
The `exit 1` ensures the target always fails after a rerun — the first run
already proved the tests are broken, so the build must not pass even if a
flaky test happens to succeed on the second attempt. The rerun exists solely
for diagnostic output.
- Docker builds must complete in under 5 minutes. - Docker builds must complete in under 5 minutes.
- `make check` must not modify any files in the repo. Tests may use temporary - `make check` must not modify any files in the repo. Tests may use temporary