func TestWhatever(t *testing.T) {
// ...lots of code
_, _, _, _, _, _, _ = resp3, resp4, fooBefore, subFoo, bar2, barNew, zap2
}
Like, I get it, it's a good feature, it caught quite a lot of typos in my code but can I please get an option to turn this checking off e.g. in unit tests? I just want to yank some APIs, look at their behaviour, and tinker a bit with the data. func TestWhatever(t *testing.T) {
var resp3, resp4, fooBefore, subFoo, bar2, barNew, zap2 theirType
// ...lots of code
}
Alternatively, use '_' where they are being defined: // instead of
resp2, err := doit()
// use
_, err := doit()
If, and given this context it's likely, you're checking these errors with asserts, then either change the name of the error variable, predeclare the err name (`var err error`), or split it into multiple tests instead of one giant spaghetti super test.That said, in a code review, at a minimum, I would probably ask that these variables be checked for nil/default which would completely eliminate this problem.
foo, fooErr := doit()
require.NotNil(foo)
require.NoError(fooErr)
_, _ = foo, fooErr // alternative if you don't want the asserts for some reason, remember to come back later and delete though
// ...repl churn code...
Using the stretchr/testify/require package. This code defines both variables, gives the error a unique name in the scope, and then references the names in two asserts. You won't have to deal with unreferenced name errors in the "repl churn", so you can comment/uncomment code as you go.https://gist.github.com/umanwizard/9793393083a42db933579fe21...
The go devs decided against this since they didn't want to build a highly optimizing (read: slow) compiler, but that is missing the point of developer ergonomics.
Most people nowadays ban building with warnings in CI and allow them during local development. But “CI” was barely a thing when go was developed so they just banned them completely. And now they are probably too stubborn to change.