[stickydink]

Seriously? That's the critique you have?

Choices like that are 100% personal preference, and belief of which is "better" again is personal opinion.

Foe the counter argument; I find it far more readable to follow the if/else blocks, than to rely on identifying which if blocks contain return statements.

Personally, I prefer a step further, keeping all if/else blocks and using a variable inside the method to track the return value, with a single return statement at the end of the method.

There are plenty of blogs and articles debating for or against every permutation of this. But in the end, it really doesn't matter one bit whether there's an else statement on line X Y and Z.

[tptacek]

One reason you're getting downvoted is that the note the parent commenter gave is pretty squarely in Go idiom. Go favors early-exit, and the Go community is unusually strict about idiom.

(I'm pretty well acquainted with this particular issue because my C coding style is strictly anti-early-exit, which drives almost everyone I work with up a wall. I had to unlearn that habit to write idiomatic Go.)

[stickydink]

Understandable, thanks for an explanation

[codo2]

It's not a critique but a suggestion. Like you are saying, it is not an error, my suggestion is simply to follow the standard library.

From golang.org Effective Go: "In the Go libraries, you'll find that when an if statement doesn't flow into the next statement—that is, the body ends in break, continue, goto, or return—the unnecessary else is omitted."