Can I stop these complaints about my unused variable/import?
The presence of an unused variable may indicate a bug, while unused imports just slow down compilation, an effect that can become substantial as a program accumulates code and programmers over time. For these reasons, Go refuses to compile programs with unused variables or imports, trading short-term convenience for long-term build speed and program clarity.
Still, when developing code, it's common to create these situations temporarily and it can be annoying to have to edit them out before the program will compile.
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.
It's easy to address the situation, though. Use the blank identifier to let unused things persist while you're developing.
import "unused"
// This declaration marks the import as used by referencing an
// item from the package.
var _ = unused.Item // TODO: Delete before committing!
func main() {
debugData := debug.Profile()
_ = debugData // Used only during debugging.
....
}
import (
"fmt"
)
import "fmt"
./Test.go:3: imported and not used: "fmt"
아래와 같이 해야 에러가 발생하지 않는다.
import (
_ "fmt"
)
func main() {
}
func main() {
i := 0
_ = i
}
'go lang' 카테고리의 다른 글
[golang] docker 빌드/실행 - ENV 없이 실행하기 (0) | 2017.09.18 |
---|---|
go 컨퍼런스 자료 (0) | 2017.09.01 |
[golang] if 예제 (0) | 2017.08.29 |
[golang] 반복문 - for / 문 예제 (0) | 2017.08.29 |
[golang] 타입 확인하는 방법 - reflect.TypeOf (0) | 2017.08.29 |