Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Avoid Else, Return Early (2013)

blog.timoxley.com

Post reply on HN
Print view View original

471–480 of 601 posts

Re: Avoid Else, Return Early (2013)

#471

Post by TomMarius »

ajuc wrote: post #158
IshKebab wrote: post #145

Earlier quoted context omitted.

> The problem with this is maintaining comments. That's like saying "the problem with healthcare is that it costs money". Of course comments can get out of date. The solution isn't to throw them out!

There's no alternative for healthcare. There's alternative to in-code comments answering the question "why" - it's commit messages. They can't be out of date.

What? So in my case I'm supposed to browse literally millions of commit messages in order to understand the code?

Re: Avoid Else, Return Early (2013)

#472

Post by jessaustin »

lackbeard wrote: post #451
Aaargh20318 wrote: post #177

Earlier quoted context omitted.

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

Code shows how it is being done. Comments should explain what is being done.

In some cases it seems that the name of a function takes care of the "what".

Re: Avoid Else, Return Early (2013)

#473

Post by lispm »

Grue3 wrote: post #238

In Common Lisp the syntax for early return is so ugly (```(return-from function-name result)```) that I use it very rarely. In general, it seems that in the languages that use implicit return (Lisps, Haskell, Rust?) having an early return is discouraged by design.

Common Lisp does not use explicit returns much, since every expression returns one (or more) values.

  (lambda ()
    (cond ((foo) x)
          ((bar) y)
          (t     z)))
Such a conditional like COND returns the value(s) of the last form in a clause -> here either the value of x, y or z.

Re: Avoid Else, Return Early (2013)

#474

Post by xg15 »

optimuspaul wrote: post #108
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 comments are extra weight that should only be in public or algorithm/need to know areas. Unless you are writing completely brilliant code your future self will hate you if you skimp on comments. Also self-documenting code is great, but intentions are not always clear to another person trying to figure out your code.

I understand that as "document every class/module/public method with javadoc/pydoc/whatever and also explain the (few!) counter-intuitive bits of your code with inline comments. (You might find those deep within an algorithm, but usually not in plumbing or business logic code)."

That should leave you with a solid documentation of your application's components and APIs and a small amount of inline comments.

If you find you have more comments, either your code should be simplified or you're commenting trivialities.

As everything, it's a guideline with exceptions, not an absolute rule.

Re: Avoid Else, Return Early (2013)

#475

Post by ropeadopepope »

ajuc wrote: post #142
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…

This is like the 10 commandments. Good ideas mixed with stuff that is a matter of taste :) If it was this simple we wouldn't be still arguing about coding styles decades after they were invented. I know few old programmers that I respect very much, and they don't agree about the perfect coding style, not even simple stuff, like braces in separate lines or not.

> If it was this simple we wouldn't be still arguing about coding styles decades after they were invented.

I disagree with the logic in this sentence. New coding styles are invented all the time. The guard statements in the article were only formalized in the late 90s, for example. These arguments about coding styles "decades after they were invented" are the only way we know which work and which don't.

It's not a matter of taste. It's how you separate the wheat from the chaff. Except for the brackets one. ;)

Re: Avoid Else, Return Early (2013)

#476

Post by seanmcdirmid »

louthy wrote: post #430
seanmcdirmid wrote: post #243

Earlier quoted context omitted.

No, you usually have to debug just as much, you just don't have any nice tools to do it with. I agree the monadic approach looks cleaner, but just be ready to undo it for any kind of hairy logic that requires debugging.

I have not found that and use it extensively. So, I respectfully disagree. Debugging isn’t significantly harder, it’s a bit harder. In VS you can break on individual LINQ expression stages, read the unpacked values, read the let values, etc. If I’m composing with Bind functions then I can always break either inside the lambda or the static function being used for the bind operation.

You can eval the arguments, but you still have to pop a stack frame on if you can at all to get at the underlying control flow. You then have to integrate all those frames by yourself in your head. Even the most ideological Scala programmer wouldn’t replace all their if statements with options.

Re: Avoid Else, Return Early (2013)

#477

Post by bsder »

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…

> 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.

Except that I see soooooo many people try to write state machine code with early return/function encapsulation just to avoid indentation.

And then they get pounded when the state machine needs to evolve--and it always needs to evolve.

I really wish programmers had to design a VLSI chip, get it manufactured and debug it just once before they get out of school. The "So THAT'S why they have a global clock that synchronizes all the parallel operations in lock step" moment tends to be blinding.

Re: Avoid Else, Return Early (2013)

#478

Post by Rusky »

Merad wrote: post #418
lisper wrote: post #309

Earlier quoted context omitted.

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.

K&R isn't that terrible when code is neat and clean, but it starts to have trouble IMO particularly when declarations or conditions wrap to multiple lines. Compare the following examples... I personally have to stop and read the code to find the blocks with K&R braces, vs being able to see them at a glance with Allman. void MyLongMethodName(SomeLongParamType param1, SomeOtherLongParamType param2, YetAnotherLongParamT…

I treat the parentheses the same way I treat the braces:

    void MyLongMethodName(
        SomeLongParamType param1,
        SomeOtherLongParamType param2,
        YetAnotherLongParamType param3
    ) {
        if (
            longContrivedVariableName1 == longContrivedVariableName2 &&
            longContrivedVariableName1 != longContrivedVariableName3
        ) {
            // do stuff
        }
    }
I also make liberal use of temporary variables:

    void MyLongMethodName(
        SomeLongParamType param1,
        SomeOtherLongParamType param2,
        YetAnotherLongParamType param3
    ) {
        auto condition1 = longContrivedVariableName1 == longContrivedVariableName2;
        auto condition2 = longContrivedVariableName1 != longContrivedVariableName3;
        if (condition1 && condition2) {
            // do stuff
        }
    }
Vertical space is allocated to the actual parameters and conditions, and the extra syntax-only lines exist only to separate chunks. This works well with "paragraphs":

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

        auto someData = buildSomeData();
        doSomethingWith(someData);
        while (someCondition) {
            // loop
        }

        finishUp();
        return someData;
    }

Re: Avoid Else, Return Early (2013)

#479

Post by slaman »

sireat wrote: post #426
tom_mellior wrote: post #216

Earlier quoted context omitted.

Do they? All the Python folks I've ever seen express an opinion on style have said "follow PEP 8". Unsurprisingly, PEP 8 does have a rule for tabs vs. spaces: https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces (spaces, of course)

I love Python but as a long time C programmer I can't understand the preference for spaces in PEP 8. Tabs are semantic and only take one key press for movement back and forth and to delete. If you see 1 tab you know it meant one indentation level. With spaces you have to think. Plus with spaces you are stuck with 2/4/8 spacing(unless you reformat), with tabs you can configure your editor to your preferences.

> with tabs you can configure your editor to your preferences.

Configure 1 tab to be 4 spaces.

Sometimes it's easier to go with the flow. I like tabs for the reasons you mentioned, but fixed-width spaces are a bit better for some reasons too. IDE's can do the heavy lifting of re-formatting indentation levels and converting tabs to spaces for me, and it means if I cat a file on a remote server regardless of the bash tab width settings or if I'm in your code or the stdlib it will all make sense.

Re: Avoid Else, Return Early (2013)

#480

Post by twic »

josephv wrote: post #270
ivanhoe wrote: post #218

Earlier quoted context omitted.

In last 20+ years I've changed the coding style many times, usually to fit the current team style. And in my experience it takes a few weeks for the brain to rewire to the new style. First you hate it, and then you get used to it, and then you're like: wow it's great. Then you switch the standards for a new project and again, the same steps. It's just a matter of habit...

Pragmatic programming has lost. If you aren't a zealot about being pedantic, just move into the old-folks home.

Well, i'm a pedant about being zealous, and i am afraid we are now doomed to war eternally.
Post reply on HN