This a followup from golang-nuts that I posted a few months back.

It would be nice if gofmt -s simplified the following redundant expressions:

if x == nil || len(x) == 0 {}
if x != nil && len(x) ... {  // or any operator len(x) > 0, len(x) != 0, len(x) > 10000

can be simplified into just

if len(x) == 0 {}
if len(x) .... {}

How common is this?

Not uncommon: While this code search on GitHub isn't perfect, it does show up. I'd prefer not to download github to correctly search until I understand the acceptance requirements (defects per 10k? at what level? number of repos affected?)

• https://github.com/search?utf8=✓&q=%22%3D%3D+nil+%7C%7C+len%28%22+extension%3Ago&type=Code&ref=searchresults
• https://github.com/search?utf8=✓&q=%22%21%3D+nil+%26%26+len%28%22+extension%3Ago&type=Code&ref=searchresults

To quote the original topic:

As a quick test I used grep, and removed false positives.

$ find . -name '*.go' | xargs grep '= nil || len(' | grep Godeps

./Godeps/_workspace/src/github.com/gocql/gocql/marshal.go: if data == nil || len(data) == 0 {
./Godeps/_workspace/src/github.com/pborman/uuid/uuid.go: if uuid == nil || len(uuid) != 16 {
./Godeps/_workspace/src/github.com/pborman/uuid/uuid.go: if uuid == nil || len(uuid) != 16 {
./Godeps/_workspace/src/github.com/ugorji/go/codec/decode.go: if rvbs == nil && bs2 != nil || rvbs != nil && bs2 == nil || len(bs2) != len(rvbs) { ### wow!!

$ find . -name '*.go' | xargs grep '= nil && len(' | grep Godeps

./Godeps/_workspace/src/github.com/araddon/gou/jsonhelper.go:if lst := jsonList(root); lst != nil && len(lst) > idx {
./Godeps/_workspace/src/github.com//elastigo/lib/clusterhealth.go: if f.FilterIndices != nil && len(f.FilterIndices) > 0 {

thats 5 repos out of 60. Granted a small sample but that doesn't seem so rare.

I reran this, a few of them have been fixed up and some new ones added.

Great for learning

Even if not particularly common, people new to Go from ruby, C/C++, java are normally terrified by nil or null and are use to putting in guards. Having this check in gofmt, make learning that the len operator understands the native type and makes code simpler. Plus it definitely makes the code easier to read.

gofmt -st vs. golint

• The check-nil-then-len anti-pattern is fundamental misunderstanding of the language (that len understands pointers and types) vs a style issues. (more like gofmt, less like golint)
• It can be coded with no false positives (again more like gofmt, less like golint)
• that said I think the -s flag in gofmt is less known than golint, and golint is decoupled from release cycles.
• There may be an issue of false negatives with gofmt. For instance, what should happen with inverted forms such as x == nil || 0 == len(x), or broken code such as if len(x) == 0 || x = nil (which I bet happens). gofmt -s simplification is very simple, while golint is more like "hey take a look at this.."

Next Steps

If this is better ingolint Great, let me know and I'll move the ticket over there.

Likewise, if this needs a formal proposal I'm happy to that as well.

And finally, I'm also happy to fill out the copyright assignment and do the actual work. You win!

ps. While writing this, "golint" got autocorrected as "goofy"