warnings_strict — macontrol evidence
The project takes a maximally strict posture on warnings, well within the "where practical" qualifier of this suggested criterion.
- Strict golangci-lint configuration (.golangci.yml)
issues:
max-issues-per-linter: 0
max-same-issues: 0
These two settings disable golangci-lint's default deduplication caps. By default golangci-lint shows only the first 50 findings per linter and the first 3 of each kind; setting both to 0 means every finding is surfaced. This is the strict-mode setting — the project wants to see all warnings, not a sampled summary.
- Strict linter selection with
default: none
linters:
default: none
enable: [errcheck, govet, ineffassign, staticcheck, unused, misspell,
gocritic, revive, bodyclose, nolintlint, unparam, prealloc, gosec]
default: none means no linters run unless explicitly enabled — so the active set is deliberate, not accidental. The 13 enabled linters include the strictest commonly-used ones:
- staticcheck (covers SA, ST, S, QF check categories — the gold-standard Go static analyser)
- gosec (security)
- gocritic (opinionated bug-pattern checks beyond go vet)
- revive with
exported and package-comments rules explicitly enabled — these enforce godoc on every exported symbol and every package, a notably strict bar
- nolintlint (polices the suppressions themselves — stale or unjustified //nolint directives are themselves warnings)
- Minimal, justified exclusions
The configuration suppresses almost nothing:
- One global exclusion: gosec G204 (subprocess invocation), with an inline comment explaining why ("Subprocess call is the whole point of this project"). Without this the entire project would be one giant warning, since shelling out to pmset/networksetup/osascript is its purpose.
- Test files exclude only gosec, unparam, gocritic — the standard Go pattern, since these produce noise on test scaffolding and assertion helpers.
- generated: lax — generated files are excluded from lint, the standard convention.
There are no broad path exclusions, no per-linter rule disables, no severity downgrades. The configuration is roughly 50 lines and contains nothing that softens the rules.
- Strict bars layered on top of golangci-lint
- govulncheck runs in CI as a separate
vuln job — any known-vulnerable dependency or stdlib usage fails the build.
- CodeQL (.github/workflows/codeql.yml) — semantic analysis on every push.
- OpenSSF Scorecard (.github/workflows/scorecards.yml) — supply-chain best-practice scoring published publicly.
- Codacy + Codecov dashboards — third-party static analysis with public badges.
- gofumpt (stricter than gofmt) and goimports (with local-prefix grouping enforced) run as formatters — formatting drift is a CI failure.
- A 30-second fuzz test (FuzzDecode) runs on every PR.
- Race detector enabled in CI tests:
go test -race.
- Strict bar raised over time, not lowered
The history shows the project tightening, not loosening, its strictness:
d0b3eaf docs: comprehensive godoc for all production code + enable strict lint (#77)
c4474e8 docs: thorough godoc rewrite with structured sections (#78)
caa55d6 fix(ci): resolve 50 golangci-lint v2 findings
The "enable strict lint" commit turned on revive's exported and package-comments rules and then brought the entire codebase into compliance — the opposite of the anti-pattern of relaxing rules to make warnings disappear.
- Evidence the strict bar is held in practice
A repo-wide grep finds only 3 //nolint directives across the codebase. Each is single-line, names the specific linter being suppressed, and carries an inline justification. nolintlint enforces this format. Three narrow, justified suppressions across ~96 production .go files is a notably tight ratio.
The macOS-target build is also configured strictly:
GOFLAGS ?= -trimpath
LDFLAGS ?= -s -w …
CGO_ENABLED=0 go build -trimpath -ldflags="-s -w" …
-trimpath removes filesystem path leakage, and -s -w strips debug info from release binaries.
- Practical limits, honestly handled
The "where practical" qualifier matters here. macontrol is a subprocess-orchestration daemon; gosec G204 (subprocess with non-constant input) cannot be globally satisfied because the project's purpose is to run macOS CLIs. The maintainer suppresses G204 globally with a documented justification rather than littering the code with per-call suppressions or pretending it's not an issue. That's the right kind of pragmatic strictness — strict everywhere it's practical, explicitly bounded where it isn't.
Summary: the project enables 13 linters with default: none, sets max-issues caps to 0 to surface every finding, enforces godoc on every exported symbol via revive, layers govulncheck + CodeQL + Scorecard + Codacy on top, uses gofumpt (stricter than gofmt), runs tests with -race, fuzzes the highest-risk parser, and has a documented history of raising the bar (enable strict lint → fix the resulting 50 findings) rather than lowering it. Only 3 narrowly justified //nolint suppressions exist in the entire codebase. The criterion is satisfied at the strong end of the spectrum.
级别条款。您还可以查看
或
级别条款。