Avoid Else, Return Early (2013)

Post by macspoofing » Mon, Mar 26, 2018, 5:24 PM UTC

RobertRoberts wrote: post #398

macspoofing wrote: post #369

Earlier quoted context omitted.

The problem is that for any rule you come up with there are cases where that rule is just too rigid and too inflexible. There are times where early return makes a ton of sense. Usually that's the case when you can derive the return value from a shallow interpretation of some input values (i.e. check preconditions) but still require more complex processing for other input values. In that case, return early, but constr…

Can't that be taught as well? (both rules, and exceptions to rules?)

Post by bjourne » Mon, Mar 26, 2018, 5:32 PM UTC

timoxley wrote: post #375

bjourne wrote: post #300

Earlier quoted context omitted.

Ceteris paribus, shorter code always is more readable. It's the only guideline I've found true regardless of programming language or environment. Shorter is better.

It depends. Short, dense code can make the code more difficult to understand/change later, while overly bloated code can have the same effect. I often find inelegant, yet straightforward solutions are generally better options than dense, mathematically pure solutions, simply because inelegant code usually relies on fewer assumptions. Noting that code rarely/never evolves the way we expect it to, apply Occam's razor a…

Post by gigatexal » Mon, Mar 26, 2018, 5:41 PM UTC

drawkbox wrote: post #65

Programmers with lots of hours of maintaining code eventually evolve to return early, sorting exit conditions at top and meat of the methods at the bottom. Same way you evolve out of one liners. Same way comments are extra weight that should only be in public or algorithm/need to know areas. Same way braces go on the end of the method/class name to reduce LOC. Same way you move on from heavy OO to dicts/lists. Same w…

Post by Merad » Mon, Mar 26, 2018, 5:57 PM UTC

lisper wrote: post #309

hailk wrote: post #293

Earlier quoted context omitted.

The start of the code block is signified by the opening brace, which starts at the end of the method name in the first case, hence breaking symmetry.

To my eye, the start of the code block is signified by the indentation, i.e.: stuffstuffstuff.... stuffstuffstuff... So I read C and Python (and Lisp) code the same way. A naked open brace looks jarring and ugly to me. It also increases the separation of other related parts of the code, i.e. if (...) { while(...) { do(...) { vs if (...) { while(...) { { do(...) { The latter seems unnecessarily wasteful to me.

    void MyLongMethodName(SomeLongParamType param1, SomeOtherLongParamType param2,
        YetAnotherLongParamType param3) {
        if (longContrivedVariableName1 == longContrivedVariableName2 && 
            longContrivedVariableName1 != longContrivedVariableName3) {
            // do stuff
        }
    }
    
    void MyLongMethodName(SomeLongParamType param1, SomeOtherLongParamType param2,
        YetAnotherLongParamType param3) 
    {
        if (longContrivedVariableName1 == longContrivedVariableName2 && 
            longContrivedVariableName1 != longContrivedVariableName3) 
        {
            // do stuff
        }
    }

Post by Kapow » Mon, Mar 26, 2018, 6:02 PM UTC

pmarreck wrote: post #411

drawkbox wrote: post #65

Programmers with lots of hours of maintaining code eventually evolve to return early, sorting exit conditions at top and meat of the methods at the bottom. Same way you evolve out of one liners. Same way comments are extra weight that should only be in public or algorithm/need to know areas. Same way braces go on the end of the method/class name to reduce LOC. Same way you move on from heavy OO to dicts/lists. Same w…

I've actually gone from avoiding else to requiring else, which is sort of a necessity when you're in a functional immutable environment where the result of a logical expression is a value (and often assigned as such), since it avoids undefined situations. (This example comes from Elixir.) value = if boolean, do: this_value, else: other_value is undefined in some circumstances unless an "else" is included. This patter…

    value = boolean ? this_value : other_value;