I think it's still required by by the MISRA-C standard, so if you write code for cars and some similar industries, you may get forcefully dragged into that church.
MISRA 2012, Rule 15.5: "Only one exit point should be defined in a function.", advisory - https://www.ibm.com/docs/en/rtr/9.0.0?topic=review-code-misr...
HN users cordenr and bfrog say it was dropped in MISRA 2023: https://news.ycombinator.com/item?id=38680587 and https://news.ycombinator.com/item?id=38704631 . Both in a recent thread on MISRA 2023 at https://news.ycombinator.com/item?id=38674158 .
FWIW, HN user FirmwareBurner in that thread links to the "Embedded System development Coding Reference guide" version 3.0 (2018) from the Software Reliability Enhancement Center, Japan at https://www.ipa.go.jp/publish/qv6pgp00000011mh-att/000065271... which says
M3.1.5:
A function shall end with one return statement.
A return statement to return in the middle of processing shall
be written only in case of recovery from abnormality.Also, that's great news to hear in case I ever want to go back to the automotive industry. :)
You could flex some language lawyering to define "abnormality"...
Here is the only relevant example I found:
p = X_MALLOC(sizeof(*p) * NUM);
if (p == NULL) {
return (MEM_NOTHING);
}
...
X_FREE(p);
return (OK);
Something like a:
if (get_size(obj) == 0) {
return empty_case;
}
... do more complicated code here ...
return result;
Logs should be output not only when an abnormal condition
is detected, but also at the timing of, such as, data
communication with an external system.People didn't understand that, too vague, hard to enforce. Someone else decided to make it clearer, "try to avoid multiple returns inside a function".
Then someone else comes and decides to tidy up the coding style document, put it in imperative form: "All functions should have a single return statement".
Give it a couple of years, people forgot why the advice was there in the first place and now they just blindly apply an insane rule, teach that to new hires and enforce it in reviews. All functions now look like big arrows and every once in a while the max line length rule has to be relaxed a little to allow for all those levels of indent.
Maybe that's how it entered MISRA-C in the first place.
But your "return" should also have all deallocations performed! Also if you open communications to some external devices which tend to be notoriously stateful, you need to bring them back to a usable state by either completing commands sent so far, or resetting them, or whatever is needed.
If there is nothing analogous to "defer" statements or "finally" clauses, you will be in a world of pain if you sprinkle return statements without paying attention to all details.
Thus I can see a point of such a rule being in MISRA-C or something like it. Guess it's better to enforce an easily checkable rule (prone to birthing monsters) than educate all people properly.
A recommendation likely lifted from one of these sources.