I'm learning Go but I feel it is a bit annoying that when compiling, I should not leave any variable or package unused.
This is really quite slowing me down. For example, I just wanted to declare a new package and plan to use it later or just uncomment some command to test. I always get the error and need to go comment all of those uses.
Is there any way to avoid this kind of check in Go?
That error is here to force you to write better code, and be sure to use everything you declare or import. It makes it easier to read code written by other people (you are always sure that all declared variables will be used), and avoid some possible dead code.
But, if you really want to skip this error, you can use the blank identifier (_) :
package main
import (
"fmt" // imported and not used: "fmt"
)
func main() {
i := 1 // i declared and not used
}
becomes
package main
import (
_ "fmt" // no more error
)
func main() {
i := 1 // no more error
_ = i
}
As said by kostix in the comments below, you can find the official position of the Go team in the FAQ:
The presence of an unused variable may indicate a bug, while unused imports just slow down compilation. Accumulate enough unused imports in your code tree and things can get very slow. For these reasons, Go allows neither.
You can use a simple "null function" for this, for example:
func Use(vals ...interface{}) {
for _, val := range vals {
_ = val
}
}
Which you can use like so:
package main
func main() {
a := "declared and not used"
b := "another declared and not used"
c := 123
Use(a, b, c)
}
There's also a package for this so you don't have to define the Use function every time:
import (
"github.com/lunux2008/xulu"
)
func main() {
// [..]
xulu.Use(a, b, c)
}
According to the FAQ:
Some have asked for a compiler option to turn those checks off or at least reduce them to warnings. Such an option has not been added, though, because compiler options should not affect the semantics of the language and because the Go compiler does not report warnings, only errors that prevent compilation.
There are two reasons for having no warnings. First, if it's worth complaining about, it's worth fixing in the code. (And if it's not worth fixing, it's not worth mentioning.) Second, having the compiler generate warnings encourages the implementation to warn about weak cases that can make compilation noisy, masking real errors that should be fixed.
I don't necessarily agree with this for various reasons not worth going into. It is what it is, and it's not likely to change in the near future.
For packages, there's the goimports tool which automatically adds missing packages and removes unused ones. For example:
# Install it
$ go get golang.org/x/tools/cmd/goimports
# -w to write the source file instead of stdout
$ goimports -w my_file.go
You should be able to run this from any half-way decent editor − for example for Vim:
:!goimports -w %
The goimports page lists some commands for other editors, and you typically set it to be run automatically when you save the buffer to disk.
Note that goimports will also run gofmt.
As was already mentioned, for variables the easiest way is to (temporarily) assign them to _ :
// No errors
tasty := "ice cream"
horrible := "marmite"
// Commented out for debugging
//eat(tasty, horrible)
_, _ = tasty, horrible
I ran into this while I was learning Go 2 years ago, so I declared my own function.
// UNUSED allows unused variables to be included in Go programs
func UNUSED(x ...interface{}) {}
And then you can use it like so:
UNUSED(x)
UNUSED(x, y)
UNUSED(x, y, z)
The great thing about it is, you can pass anything into UNUSED.
Is it better than the following?
_, _, _ = x, y, z
That's up to you.
In case others have a hard time making sense of this, I think it might help to explain it in very straightforward terms. If you have a variable that you don't use, for example a function for which you've commented out the invocation (a common use-case):
myFn := func () { }
// myFn()
You can assign a useless/blank variable to the function so that it's no longer unused:
myFn := func () { }
_ = myFn
// myFn()
One angle not so far mentioned is tool sets used for editing the code.
Using Visual Studio Code along with the Extension from lukehoban called Go will do some auto-magic for you. The Go extension automatically runs gofmt, golint etc, and removes and adds import entries. So at least that part is now automatic.
I will admit its not 100% of the solution to the question, but however useful enough.
As far as I can tell, these lines in the Go compiler look like the ones to comment out. You should be able to build your own toolchain that ignores these counterproductive warnings.
I ran into this issue when I wanted to temporarily disable the sending of an email while working on another part of the code.
Commenting the use of the service triggered a lot of cascade errors, so instead of commenting I used a condition
if false {
// Technically, svc still be used so no yelling
_, err = svc.SendRawEmail(input)
Check(err)
}
_is still a very cumbersome work around which demonstrably breaks developer flow. Every single time you comment something out you then need to go and stub all thedeclared but not usederrors. Any team could implement standards and style checks as a commit hook or part of a CI/Gate job. The lack of agency given to developers here is patronizing and furthermore forces us to write worse code in order to be able to pull things apart.goimportssolves the issue for imports, a compiler flag should be acceptable for variables. – Simon Merrick