Mmm, I disagree. Influenced by functional programming, I prefer to use the style of: "keep all return statements at the same indentation level" in statement ba

Mmm, I disagree. Influenced by functional programming, I prefer to use the style of: "keep all return statements at the same indentation level" in statement based languages. This way, it is easier to parse as an expression. For example: if (...) { let a = ...; return x(a); } else { return y; } Can be easily mentally factored into the pseudo-expression: return ... ? x(...) : y; It is easier to see what the side-effects (or ideally lack of) are. It also makes case analysis easier, and you don't hide the fact that you have 2^{indentation levels} number of possible states. Early return while excusable for some very particular and idiosyncratic error handling examples (e.g. fortified C APIs that accept null pointers as no-ops) in general feels like "cheating", making the code look less complicated than it actually is (it "silently" multiplies the size of your state space without increasing indentation). But most importantly, it puts too much emphasis on control flow: I'd rather emphasize the underlying declarative intent, the state machines, and pre/post-conditions. This is is better achieved, in my opinion, by trying to delay returns, and to try to minimize the amount of code after a branching (this often means having unnecesary else branches, that on the other hand help with readability.) As shown before, this helps mentally factoring the code into reducible expressions and guessing state space and overall complexity. I agree though that having one single-return is not good, cuz most of the time it forces one to use mutable variables that could otherwise be avoided.