Statements that drastically change the program's control flow (like return) should be prominent and easy to spot. Inlining an if-return like that makes it less visible. It may be ok when the return statement is the whole body of the function, like in

func add(a, b int) { return a + b }

(which is allowed by gofmt), but I don't think it is when it's a jump buried inside an if somewhere in the function.

@ALTree if functions are so big you can't spot a return statement inside an if statement then the issue is with the cleanliness of the code, I think allowing to inline if-return will help reduce the clutter in the eyes.

Small functions or even just functions that adhere to Command & Query separation will not have the issue you describe.

Thanks for the quick reply!

I wholeheartedly support this. I never dared to push it because I'm sure it has been discussed before. Just to get the typical pro arguments out there:

• Vertical space is much scarcer than horizontal space nowadays (with most people having 16:9 screens or similar).
• It's been allowed for functions and that freedom has not caused much friction between people in my experience. So I doubt not enforcing a canonical format will be a major issue.
• Almost everyone I talked to about this is unhappy about how much space the current formatting wastes and how much it distracts from the more interesting lines (almost 3:1 loc ratio of trivial error handling cod VS other code happens in some cases).
• Adding distance between lines of code makes code more difficult to understand and read. People forget stuff if they need to scan or scroll.

@FlorianUekermann

Adding distance between lines of code makes code more difficult to understand and read. People forget stuff if they need to scan or scroll.

People forget stuff when there is too much information in the brain short memory any way. Making the code less line can not solve this problem.
Two statement one line may need the brain store more information, like there is two thing in that line, one thing in this line, the horizontal position of the statement. If all lines only have one statement, the brain do not need to store that information, it just need remember the vertical position of the statement.
If someone is smart, he can understand and remember the code with two statements in one line or one statement in one line easily. But I think he should sympathize his colleague which is not so smart. He also should put his smart into the real problem(like data race/dead lock/use too much memory) he need to solve.

Vertical space is much scarcer than horizontal space nowadays (with most people having 16:9 screens or similar).

The screen is big so you can see two files or three files in vertical parallel.

Also note:

• Putting two statements in one line can be used to cheat line based test coverage tool.
• Putting two statements in one line can make the panic stack trace more difficult to debug, since the panic stack trace only have line number.

@bronze1man
I agree that generally one line should do 1 thing but in my experience when the line is short enough if-returns as well as terinary operator usages are easy enough to follow, I agree that they could potentially be missed in long functions but for short ones that issue doesn't exist IMHO

It seems they are going to solve the clutter issue in go 2 by having a block of error handling, so that might solve the core issue

See also...
Go2 drafts error handling: https://go.googlesource.com/proposal/+/master/design/go2draft.md
Community feedback: https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback

We decided long ago not to allow this kind of density. If the problem is specifically error handling, then we have other ideas for that (as noted). But the decision that there are no 1-line if statements is done.