This code
package main
import (
"fmt"
)
func main() {
fmt.Println("%%dude")
}
Playground link: https://play.golang.org/p/Shq5pMHg4bj
gives a go vet warning
./prog.go:8:2: Println call has possible formatting directive %d
How can I tell go vet that I really want to write two percent signs and not to warn me?
You can't really supress that, but even if you could with custom rules and flags, I wouldn't do it because someone else building your code will still run into this.
Instead you may use any of these alternatives which produce the same output without any warnings from vet:
fmt.Println("%%"+"dude")
fmt.Println("%\x25dude")
fmt.Printf("%%%%dude\n")
s := "%%dude"
fmt.Println(s)
Try the examples on the Go Playground.
You can't really (apart from not writing that code). Go vet doesn't have any mechanism for "I really meant this" comments to suppress warnings. There have been several discussions about it in the past five years, none of which have resulted in any action. You just have to accept what the help text says: go vet "uses heuristics that do not guarantee all reports are genuine problems".
Related
There's a lot of examples in test code that are shadowing package names in test libraries like testify.
For example:
import (
"testing"
"github.com/stretchr/testify/assert"
"github.com/stretchr/testify/require"
)
func TestSomething(t *testing.T) {
assert := assert.New(t)
require := require.New(t)
var a string = "Hello"
var b string = "Hello"
assert.Equal(a, b, "The two words should be the same.")
}
Shouldn't it be an explicit decision and rare occurrence to override the value of a package namespace with a local variable?
import (
"testing"
"github.com/stretchr/testify/assert"
"github.com/stretchr/testify/require"
)
func TestSomething(t *testing.T) {
assertions := assert.New(t)
req := require.New(t)
var a string = "Hello"
var b string = "Hello"
assert.Equal(a, b, "The two words should be the same.")
}
I'd expect the proper behavior to be aliasing the package like pkgassert which I doesn't feel idiomatic, or ensuring that variables are not set to the same name as the package: assertions := assert.New(t).
Other examples:
Ok: buf := bytes.Buffer{}
Bad: bytes := bytes.Buffer{}
Note: I'm not focused on variable naming patterns, as Go tends to recommend single letter, or short variables in the narrowed scope you might use the buffer for. Assume the longer name is acceptable and desired due to the function length.
If this is a desired behavior in testing packages I'd like to know why?
It appears to violate a key principle of idiomatic Go in "no magic" and being readable.
If there are undesired side effects from this I'd like to know of that as well.
My assumption is that is means after import that any calls to the package in the same scope wouldn't work due to variable shadowing
Edit
Scope Shadowing in Go was a nice read and gave some great points on usage. The main takeaway I had from this and from Stack commenters:
It can enhance readability. (I think this is probably due to Go preferring small concise naming for packages, making package names in Go variable length.)
Parallel Test Issues was something I recall reading a while back. I didn't understand the recommendation to "hide" the loop variable by putting in:
for _, tc := range tests {
tc := tc
t.Run(tc.name, func(t *testing.T) {
t.Parallel()
// Here you test tc.value against a test function.
// Let's use t.Log as our test function :-)
t.Log(tc.value)
})
}
}
With a better understanding of shadowing, I'm seeing this "hiding" was talking about shadowing the caller scope variable of tc by assigning inside the loop, thereby shadowing.
This seems like a good use case, though I still feel it is being "clever" rather if not commented, and violates the idiomatic Go goals of being clear and readable with no "magic".
After reviewing all the feedback and writing I've seen I'm going to summarize the findings here.
If you are investigating this behavior after seeing Go linting alerts from a tool like Goland, hopefully this answer will save you same time and make clear that it's ok, idiomatic, and only in some cases of reusing the actual package calls after initializing would any issues be experienced.
Shadowing Package Names With Local Variables
This is a matter of opinion, there is no official statement indicating this is considered non-idiomatic code.
Opinions seem to overall lean towards avoiding shadowing unless intentionally done for clarity & readability, but this is again opinion, not a requirement.
Once overridden, the package would be unavailable in that scope as the package name has been shadowed by the local variable.
I've observed that this behavior seems more likely in Go than some languages, because Go prompts package names that are short, not multi-word, and easy to type. It seems inevitable that assert := assert.New(t) could result when this happens.
Consistency, as always in matters like this, is the key. If a team determines to never shadow the package name, then assertions := assert.New(t) could be used, or as mentioned the package could be aliased such as import tassert "github.com/stretchr/testify/assert". This is an opinion standard, and either way is legal and considered idiomatic.
In the case of testing, this is commonly done as further usage of the package after the initial variable set isn't used further. Example below using the is is package. Package author comment on this (again this is opinionated, but it doesn't break anything to use it with is := is.New(t).
package package_test
import (
"testing"
"package"
iz "github.com/matryer/is"
)
func TestFuncName(t *testing.T) {
is := iz.New(t)
got := FuncName()
want := ""
is.Equal(got,want) // AssertMessage
}
Shadowing Behavior Can Address Goroutine Variable Issues
Shadowing is a known behavior and documented clearly in Effective Go.
The bug is that in a Go for loop, the loop variable is reused for each iteration, so the req variable is shared across all goroutines. That's not what we want.
It may seem odd to write req := req but it's legal and idiomatic in Go to do this. You get a fresh version of the variable with the same name, deliberately shadowing the loop variable locally but unique to each goroutine.
This can be solved without shadowing by passing in the variable as a parameter into the embedded func as well, simplifying the code. Both are legal and considered idiomatic per the guide.
Shadowing for Tests
Related to this goroutine behavior, but in the context of a testing, parallel tests run in goroutines, and therefore benefit from this pattern as well.
The tc := tc statement is required in the parallel test example because the closure runs in a goroutine. More generally, the tc := tc idiom used in the context of closures where the closure can be executed after the start of the next loop iteration - credit #gopher in comments
The gist on Be Careful With Table Driven Tests mentions this behavior as well in the How To Solve This.
Detecting
The check go vet can check for shadowing, but is not considered part of the stable package, and was removed here related to GitHub Issue 29260 and GitHub Issue 34053.
The change seems to have been prompted for compatibility purposes due to the requirement of unsafeptr flag. Additional comments seem to point towards also requiring better heuristics before allowing in go vet without being experimental.
Go Vet Shadow
Instructions on running via go vet: Package Variables With Instructions:
go install golang.org/x/tools/go/analysis/passes/shadow/cmd/shadow
go vet -vettool=$(which shadow)
For those wanting to lint this, golangci-lint does have an option to configure shadowing checks in the configuration (search for check-shadowing as no bookmark to that text block`.
Further Reading
Scope and Shadowing in Go
Scopes and Closures
Wow, that is awful code. While it might not be a compiler enforced rule, if I see this:
import "github.com/stretchr/testify/assert"
Then in that file, as far as I'm concerned, any identifier spelled assert is the top level import from that package, period. Anyone who breaks that pattern, in the name of being "clever" or whatever, is just asking for trouble. People's muscle memory is trained to recognize top level imports, so please, do not do stuff like this. If you want to avoid thinking of a new name, just remove some letters:
asrt := assert.New(t)
or add a letter:
nAssert := assert.New(t)
or alias the import:
import tAssert "github.com/stretchr/testify/assert"
Just please, do not follow the poor example given in that code.
I'm brand new to Go and trying to inspect a method argument. I've got the following code
func (c *controller) OrderNew(ctx echo.Context) error {
When I try either:
fmt.println(ctx)
fmt.Printf("%v \n", ctx)
I get
&{0xc4200f21e0 0xc4202302d0 /order [] [] map[] 0x4092860 map[site_key:2] 0xc4200bb6c0}
I realize *controller is a pointer and the values returned contain addresses, but not sure how to really debug or inspect further. I also see functions called on cxt like
ctx.Get and ctx.Render
which I realize are functions in echo.Context
Any help/clarification is appreciated. Thanks!
use log package.
log.Printf("CONTEXT %+v", ctx)
https://echo.labstack.com/guide/context is an excellent source for looking into echo.
offline there is godoc functionality, which helps with understanding any package(which is downloaded in your machine). In your case this can be done, godoc github.com/labstack/echo Context on your command line.
There are GOTO functionalities many editors that lets you see the library source, while you are coding, https://github.com/fatih/vim-go, https://github.com/DisposaBoy/GoSublime are such examples. What they allow you to do is to navigate these functions and structs to the point where they are defined. Hopefully, someone will have written, a crisp documentary comment there.
if all you want is to watch the execution of your code, you can use debugging tools, like delve https://github.com/derekparker/delve.
With the following code, go vet does not show an "out of bounds" error as I would expect:
package main
func main() {
a := make([]string, 1)
a[2] = "foo"
}
From the go vet documentation:
Flag: -shift
Shifts equal to or longer than the variable's length.
If go vet is not the tool to catch these errors, what is? Compiling and/or testing the code will catch this, but I'm looking for a static analysis based tool.
Its true that Go vet is for catching suspicious runtime error, by using some heuristics. The first Para is exact regarding its work
Vet examines Go source code and reports suspicious constructs, such as Printf calls whose arguments do not align with the format string. Vet uses heuristics that do not guarantee all reports are genuine problems, but it can find errors not caught by the compilers.
also in documentation its mentioned that
Note that the tool does not check every possible problem and depends on unreliable heuristics.
also the code which you are using to check for vetting your package is something very difficult to find by those heuristics as you are using a dynamic slice which can be appended or modified at runtime.
thereby not a perfect heuristic can be thought about for that.
fmt.Printf("%d", "scsa", "DSD")
those heuristic can catch things like this it all depends on what the training data is.
So vet should be a tool to take a quick look whether there is some general mistake which has been missed by you (If It gets caught :-) )its nothing like a compile tool or runtime checker it just runs some heuristics on the plane code you have written.
also documentation provides a list of available checks some examples are
Assembly declarations,
Copying locks,
Printf family,
Methods,
Struct tags,
etc there are many, you can see and read the complete documentation
By default, Go treats unused import as error, forcing you to delete the import.
I want to know if there exists some hope to change to this behavior, e.g. reducing it to warning.
I find this problem extremely annoying, preventing me from enjoying coding in Go.
For example, I was testing some code, disabling a segment/function. Some functions from a lib is no longer used (e.g. fmt, errors, whatever), but I will need to re-enable the function after a little testing. Now the program won't compile unless I remove those imports, and a few minutes later I need to re-import the lib.
I was doing this process again and again when developing a GAE program.
Adding an underscore (_) before a package name will ignore the unused import error.
Here is an example of how you could use it:
import (
"log"
"database/sql"
_ "github.com/go-sql-driver/mysql"
)
To import a package solely for its side-effects (initialization), use
the blank identifier as explicit package name.
View more at https://golang.org/ref/spec#Import_declarations
The var _ = fmt.Printf trick is helpful here.
I have the same problem. I understand the reasoning for why they implemented the language to disallow unused imports and variables, but I personally find this feature annoying when writing my code. To get around this, I changed around my compiler to allow optional flags for allowing unused variables and imports in my code.
If you are interested, you can see this at https://github.com/dtnewman/modified_golang_compiler.
Now, I can simply run code with a command such as go run -gcflags '-unused_pkgs' test.go and it will not throw these "unused import" errors. If I leave out these flags, then it returns to the default of not allowing unused imports.
Doing this only required a few simple changes. Go purists will probably not be happy with these changes since there is good reason to not allow unused variables/imports, but I personally agree with you that this issue makes it much less enjoyable to code in Go which is why I made these changes to my compiler.
Use goimports. It's basically a fork of gofmt, written by Brad Fitzpatrick and now included in the go tools packages. You can configure your editor to run it whenever you save a file. You'll never have to worry about this problem again.
Use if false { ... } to comment out some code. The code inside the braces must be syntactically correct, but can be nonsense code otherwise.
If you are using the fmt package for general printing to console while you develop and test then you may find a better solution in the log package.
A lot of people have already commented with valid justification and I also acknowledge the original author's intention. However, Rob Pike mentioned in different forums that Go is the outcome of simplification of the processes that a few other mainstream programming languages either lack or not easy to achieve. It's Go's language semantics as well as to make the compilation faster, there are a lot of things that are adopted which initially seems inefficient.
To make it short, unused imports are considered as errors in Go as it blots the program and slows down the compilation. Using import for side effect (_) is a workaround, however, I find this confusing at times when there is a mix of valid imports with side effects along with side effects imported purely for the purpose of debugging/testing especially when the code base is large and there is a chance to forget and not delete unintentionally which may confuse other engineers/reviewers later. I used to comment out the unused ones, however, popular IDEs such as VS code and Goland can use goimports easily which does the insertion and deletion of the imports pretty well. Please refer to the link for more info, https://golang.org/doc/effective_go.html#blank_import
put this on top of your document and forget about unused imports:
import (
"bufio"
"fmt"
"os"
"path/filepath"
)
var _, _, _, _ = fmt.Println, bufio.NewReader, os.Open, filepath.IsAbs
I cam across some code today that suprised me with a 'print' that wasn't defined. After a little playing I determined that you can just use a print to get things dumped to the console
e.g.
print("Hello World")
So it seems to be some sort of builtin but I can't find any reference to it (and I thought the go rules were lowercase functions never imported anyway)
Is this well known and if so are there other convenience functions or am I just very, very confused?
One other point -- this print doesn't use the magic formatting tricks (%v) of fmt.Printf -- If you print maps or structs you seem to get their address.
print and println are defined here.
Their purpose is explained here.
You are right, and someone else has already complained about it. It's been added to the built-in documentation for the next Go release (go1.2).
Package builtin
func print
func print(args ...Type)
The print built-in function formats its arguments in an
implementation-specific way and writes the result to standard error.
Print is useful for bootstrapping and debugging; it is not guaranteed
to stay in the language.
func println
func println(args ...Type)
The println built-in function formats its arguments in an
implementation-specific way and writes the result to standard error.
Spaces are always added between arguments and a newline is appended.
Println is useful for bootstrapping and debugging; it is not
guaranteed to stay in the language.