I always found this type of "general purpose" coding rules rather useless and often counter-productive because some coders (especially beginners) will often car

I always found this type of "general purpose" coding rules rather useless and often counter-productive because some coders (especially beginners) will often cargo-cult and apply them without rhyme or reason. I've known coders who had the opposite rule: never have more than one return per function, use if/elses for the control flow (TFA mentions that). I don't know where this rule came from and neither did they, it's just how they were taught I suppose. Replacing that with yet an other "rule of thumb" is a bad idea IMO. Writing clean and maintainable code is as art and requires balancing many variables. Sometimes an early return is warranted, sometimes an if/else might make more sense. If you're writing C code and you need to release some resource before returning (mutex, file handle etc...) then an early return might be error-prone and an "else" or "goto" might result in cleaner and more readable code. I use gotos a lot in error handling in C, I think it's a superior pattern to the one proposed by TFA if you have a lot of cleanup to do. In C++ and other object-oriented languages it's less of an issue thanks to RAII and/or GC. Beyond that if/else might be more readable if both clauses are on the same "level" semantically. For instance if you write: if (some_cond) { do_a(); return; } do_b(); It looks like `do_a` and `do_b` are not on the same "level", semantically speaking. If instead they're two variations of the same concept then an else might make more sense.