Coding Style
Coding style at go-openapi
TL;DR
Let’s be honest: at
go-openapiandgo-swaggerwe’ve never been super-strict on code style and linting.But perhaps now (2025) is the time to adopt a different stance.
Even though our repos have been early adopters of golangci-lint years ago
(we used some other metalinter before), our decade-old codebase is only realigned to new rules from time to time.
Now go-openapi and go-swagger together make up a really large codebase, which is taxing to maintain and keep afloat.
Code quality and the harmonization of rules have thus become things that we need now.
Meta-linter
Universally formatted go code promotes ease of writing, reading, and maintenance.
You should run golangci-lint run before committing your changes.
Many editors have plugins that do that automatically.
We use the
golangci-lintmeta-linter. The configuration lies in.golangci.yml. You may read the linter’s configuration reference for additional reference.
Linting rules posture
Thanks to go’s original design, we developers don’t have to waste much time arguing about code figures of style.
However, the number of available linters has been growing to the point that we need to pick a choice.
We enable all linters published by golangci-lint by default, then disable a few ones.
Here are the reasons why they are disabled (update: Nov. 2025, golangci-lint v2.6.1).
As you may see, we agree with the objective of most linters, at least the principle they are supposed to enforce. But all linters do not support fine-grained tuning to tolerate some cases and not some others.
When this is possible, we enable linters with relaxed constraints.
Final note: since we have switched to a forked version of stretchr/testify,
we no longer benefit from the great testifylint linter for tests.