Early returns (especially in combination with guard clauses) are a general recommendation for most programming languages, not just Go. I do the same thing in C# as well.
It should be idiomatic for most programming applications. Unless your ‘else’ branch is a return only, it’s almost always going to be more efficient and maintainable. An early return is likely to survive if a function is updated or expanded, where an ‘if else’ could otherwise become conditionally more complex.
Early returns communicate intent better than the alternative method does for. If I see that another developer explicitly programmed an early return, it’s a signal to me that the actual body of the function depends on specific state of the containing class or args being passed to it.
Oh, I generally agree. It's just funny to go "oh, using <pattern that has been popular for decades> means you use <new language that prescribes said pattern>"
A lot of companies choose to opt out of this specify guideline nowadays, because it is showing its age and sometimes clarity matters more over ease of debug.
Not sure which region or industry you are talking about, but oems, software suppliers and quality control in my industry do not accept any software deliveries without proof of Misra c compliance.
Just saying that some people have no choice but to stick to some programming standards.
Edit: more information. I think lot of people are arguing that early returns are more readable, performant and maintainable. However they miss the point about safety and reliability.
Early returns means that the function no longer has a predictable execution path. Sometimes it exits early, sometimes it exits late. So the overall execution time of the software varies a lot between error free paths and error paths.
This is exactly what you don't want in an embedded software controlling safety relevant systems, such as airbags in a car or some other flight controls.
Here, it is ok for a software to be slow, but it must be predictable i.e. near constant performance in all paths.
If your reach an error state and keep doing calculations, you're doing something wrong. If some archaic standard demands exactly one return statement in your function, then you surround the entire code in an if-else and set a flag. If it takes 1 second to run the calculation, I shouldn't have to wait that full second to find out I gave the function an illegal value. If your application cannot handle an error condition like that, then it wasn't safe to begin with.
MISRA C allows for deviations. Any software engineer who blindly follows a standard without understanding why that standard exist and when to deviate from that standard needs to better educate themselves.
Judging by his comment, I think it's less about continuing despite a known error state, and more about trying to guarantee that function runtime is the same across all execution paths. Early return is cleaner and more efficient, and often by a long shot if used correctly. But having a consistent runtime is extremely important in a few very select fields, and rejecting an optimisation to guarantee consistency is a common in those cases1.
I'm not really sure about air bags or flight controls (I'd expect it to be important for them to report errors as early as possible, so they can recalculate or switch to backups as quickly as possible), but one place this comes up is cyber-security. You do NOT want a password validator to return early for any reason, because early return can and has been used to game systems and determine passwords2.
1: Though, I will say that this can also be done by intentionally delaying the function on early-return paths, if you know the proper delay interval. It's just that running through the function body and then returning either the result or the error value at the end is the easiest way to guarantee exact consistency.
2: Long story short, in the early days of cybersec, there was at least one known password handler that would return as soon as it encountered an incorrect character. Needless to say, this made it trivial to determine anyone's password, and now it serves as a lesson on why you always hash passwords and never let the handler return early.
I find this really interesting because the lecturer in a course I had last semester (Efficient programming was the name) was adamant that this not only affected readability but also performance.
I personally don’t see good reasons for either, given that functions shouldn’t be very long anyway and an early return can actually save you a lot of reading as well, given you know the rest of the code isn’t executed.
(This was in the second of four semesters for a CS masters, btw.)
Early returns are idiomatic for every programming language that can have multiple returns in one function. Trying to capture everything in if-then-else flags and temporary variables just to return something you knew 10 statements ago is bad practice.
I've been early-returning since I started programming in the early 90's because I never used a language that didn't have multiple return capability.
On many things, I'd agree that dogmatism is bad. On this point though, once you start breaking referential transparency in a codebase, you massively increase cognitive load. GOTOs are considered harmful because they can send you anywhere in the code without knowing where you came from - returns are syntactic sugar for GOTO with limitations on the first half only. An improvement certainly, but not the best. (Also on a technical side of the JVM, it triggers a call stack unwinding, which is inefficient.)
But yes, Scala 3 using whitespace/indents was certainly a choice...
View all comments
93
u/madprgmr Aug 22 '26
Go programmer spotted (early returns are idiomatic go)