Go language warnings and errors
It seems that GO language does not have warnings in it. I've observed few instances. 1. "declared and not used"(if开发者_JAVA百科 variable is declared and not used anywhere it gives an error and does not compile the program) 2. "imported and not used"(similarly if package is imported and not used anywhere it gives an error and does not compile the program) Can somebody help. If they have any pointers.
Go is trying to prevent this situation:
The boy is smoking and leaving smoke rings into the air. The girl gets irritated with the smoke and says to her lover: "Can't you see the warning written on the cigarettes packet, smoking is injurious to health!"
The boy replies back: "Darling, I am a programmer. We don't worry about warnings, we only worry about errors."
Basically, Go just wont let you get away with unused variables and unused imports and other stuff that is normally a warning on other languages. It helps put you in a good habit.
The Go Programming Language FAQ
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. Accumulate enough unused imports in your code tree and things can get very slow. For these reasons, Go allows neither.
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. .... }
One solution for unused imports is to use goimports, which is a fork of gofmt. It automatically adds missing imports and removes unused ones (in addition to formatting your code).
http://godoc.org/code.google.com/p/go.tools/cmd/goimports
I've configured my editor to automatically run goimports whenever I save my code. I can't imagine writing go code without it now.
From what I just read, (wikipedia) "Go's syntax includes changes from C aimed at keeping code concise and readable."
The word "concise" is very important to the compiler. I have found out that the syntax enforced by the compiler is no longer "\n" or whitespace agnostic. And there are no "warning" type errors.
There are good things about Go. There are some not so good things. The attitude of no warnings is a bit extreme, especially when developing or testing a new package. It seems that partial development is not acceptable. Warnings are not acceptable. It is either the production version or the highway. This is a very dualistic point of view. I wonder if evolution would have resulted in "life", if that had been the constraints on nature.
I can only hope that things will change. Death seems to be very beneficial at times. I have tried Go, and I am disappointed. At my age I don't think I will return.
精彩评论