Avoid Else, Return Early (2013)

Post by lackbeard » Mon, Mar 26, 2018, 6:59 PM UTC

Aaargh20318 wrote: post #177

fouc wrote: post #119

Earlier quoted context omitted.

Only "brilliant" code ends up needing comments. Plain code organized into understandable methods (usually no more than half a page of code), with good naming for variables & method names reduces the need for comments. It's also easier to scan/read code if there's a minimum of comments in the way.

> Only "brilliant" code ends up needing comments. Code shows what is being done. Comments should explain why it's being done.

Post by crooked-v » Mon, Mar 26, 2018, 7:05 PM UTC

Kapow wrote: post #420

pmarreck wrote: post #411

Earlier quoted context omitted.

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…

That's just a ternary operator. I use that in Java all the time. value = boolean ? this_value : other_value; If the branching logic gets too complicated, I usually move it into a function (private method) with a return in each branch.

  let value = do {if (boolean) { this_value } else { other_value }}

Post by icedchai » Mon, Mar 26, 2018, 7:07 PM UTC

Merad wrote: post #106

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…

> Same way braces go on the end of the method/class name to reduce LOC. Screw that. I've been writing code for 15 years, and Allman style braces make it so much easier to mentally parse code into blocks that they're worth every single LOC. I can't speak for anyone else but I'm not working on an 80x24 terminal anymore.

Post by contravariant » Mon, Mar 26, 2018, 7:16 PM UTC

vortico wrote: post #327

contravariant wrote: post #306

Earlier quoted context omitted.

If you didn't want a pointer you could have just used something like: template struct FooWrapper { TFoo foo; const TDestr destroyFoo; template FooWrapper(Tinit initializeFoo, TDestr destroyFoo) : destroyFoo(destroyFoo) { foo = initializeFoo(); if (!foo) throw FooException(...); } ~FooWrapper() { destroyFoo(&foo); } } Although really that should have been part of the "Foo" class itself, but if you need to deal with ex…

Oh yes, I forgot to make it clear that `Foo` is a C struct from a C API. There are tens of thousands of such libraries. An issue with your wrapper is that it is not generic enough and thus must be written for each Foo-like object. That could likely be fixed with more template arguments, but of course there are multiple ways to initialize C objects like - `fooInitialize(Foo foo); // expects that foo is pre-allocated`…

Post by wutbrodo » Mon, Mar 26, 2018, 7:17 PM UTC

mercer wrote: post #334

This is one of the reasons why I grew to really love function overloading, especially in combination with pattern matching (I learned both first with Clojure, perhaps, but have only become comfortable with them now with Elixir). I can often avoid if/then statements altogether! It's also interesting how error handling becomes much less of an issue. I do a lot of javascript programming, and it's often quite frustrating…