Hacker News new | ask | show | jobs
by redbad 4571 days ago
A mix of lint-y and style problems, and over-use of named returned parameters.

https://github.com/cloudflare/bm/blob/master/src/bm/bm.go#L4...

-- comment block should start with Dictionary.

https://github.com/cloudflare/bm/blob/master/src/bm/bm.go#L5...

-- comment should precede the declaration.

https://github.com/cloudflare/bm/blob/master/src/bm/bm.go#L6... and others

-- spurious newlines

https://github.com/cloudflare/bm/blob/master/src/bm/bm.go#L7...

-- needless named return parameters

https://github.com/cloudflare/bm/blob/master/src/bm/bm.go#L1...

https://github.com/cloudflare/bm/blob/master/src/bm/bm.go#L1...

https://github.com/cloudflare/bm/blob/master/src/bm/bm.go#L2...

(many others)

-- prefer early return or continue over if/else

https://github.com/cloudflare/bm/blob/master/src/bm/bm.go#L1...

-- more boilerplate due to the needless decision to use named return params

2 comments

Happy to take a pull request from you for those improvements. We open sourced stuff partially so that we get feedback on the code, and I'm always happy to learn from others.
Named return parameters are unfortunate. Probably better to never use them unless you have to (like if you are "catching" a panic). Otherwise, I think you are nitpicking a bit.
I don't mind using named returns a lot--they can help to document, and sometimes they save you a declaration you were going to do in the method body anyway.

There are times they can be redundant (Sum(ints) does not need its return value named), or make the code less clear, or they indicate that you're trying to work around having overcomplicated methods by documenting them--I'm not saying always use them. But I don't try to avoid them.

That usage with recover would be to be able to set return parameters that might otherwise be returned as their zero values, correct?
Exactly. You can't return from the outer function in a defer, but you do have access to named return values. It's a bit of a kludge.
What's wrong with named return parameters?
http://golang.org/doc/effective_go.html#named-results

It's far more convenient looking at the function deceleration and knowing what comes and goes instead of hunting for return statements.