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

591–600 of 601 posts

Re: Avoid Else, Return Early (2013)

#591

Post by lokedhs »

jrimbault wrote: post #91
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…

>braces go on the end of the method/class name to reduce LOC You could argue the placement of braces with lots of valid arguments both way, but this... to reduce LOC ? Doesn't feel like a valid reason in any language using braces...

I've always wonder why no C or Java code formatter tool allows me to use Lisp-style formatting. It's clearly superior, and the popularity of Python should prove that people are OK with not having closing braces on their own lines:

    void foo(int x) {
        if(x == 0) {
            bar() }}

Re: Avoid Else, Return Early (2013)

#592

Post by timoxley »

arghwhat wrote: post #564
timoxley wrote: post #409

Earlier quoted context omitted.

> which might promote misunderstanding of the behavior This isn't a misunderstanding, binary logical operators in JS short-circuit like this by design. I believe && and || returned a boolean value in the past, but were explicitly changed to support this behaviour.

Quoting ECMA-262 First Edition (June 1997), Chapter 11, Section 11 (Binary logical operators)[1]: The production LogicalANDExpression : LogicalANDExpression && BitwiseORExpression is evaluated as follows: 1. Evaluate LogicalANDExpression. 2. Call GetValue(Result(1)). 3. Call ToBoolean(Result(2)). 4. If Result(3) is false, return Result(2). 5. Evaluate BitwiseORExpression. 6. Call GetValue((Result(5)). 7. Return Resul…

> the behavior has always been

The ECMA spec only defines Javascript 1.3 and above. See this description for logical operators for Javascript 1.1: https://web.archive.org/web/20060318153542/wp.netscape.com/e...

Re: Avoid Else, Return Early (2013)

#593

Post by wutbrodo »

mercer wrote: post #570
wutbrodo wrote: post #459

Earlier quoted context omitted.

> While I by no means hate Javascript, I have to admit I feel a bit silly about being defensive about it in the past. I just didn't know what I was missing, or didn't see what the big deal was. I'm glad to hear a perspective like this. I'm fortunate enough to not come across too many people like this, but I'm always utterly baffled by people who get defensive about the smallest complaints about Javascript (of which t…

Ha, well, not to get too defensive about my past defensiveness, this was at a time where the irrational hatred was constant and unrelenting. Some time after the 'Javascript: The Good Parts' book, but before all the ES6 goodies. Just a few weeks ago I had some badstalgia when I mentioned I did front-end development to someone. He responded with a rant about how real programmers don't use javascript, and how it was wri…

> Ha, well, not to get too defensive about my past defensiveness, this was at a time where the irrational hatred was constant and unrelenting. Some time after the 'Javascript: The Good Parts' book, but before all the ES6 goodies.

Yea, it's a crappy feedback loop, where unfairness on either side leads to people being even more strident in their position[1].

> He responded with a rant about how real programmers don't use javascript, and how it was written in ten days, and so on.

Ugh yea, that's exactly the kind of person I'm talking about. I may be dismissive about JS as a language, but the idea that "real" devs don't use it is ridiculous.

[1] though I admit I can't really relate to people taking their choice of programming language personally. To quote pg, "keep your identity small"

Re: Avoid Else, Return Early (2013)

#594

Post by jrimbault »

lokedhs wrote: post #591
jrimbault wrote: post #91

Earlier quoted context omitted.

>braces go on the end of the method/class name to reduce LOC You could argue the placement of braces with lots of valid arguments both way, but this... to reduce LOC ? Doesn't feel like a valid reason in any language using braces...

I've always wonder why no C or Java code formatter tool allows me to use Lisp-style formatting. It's clearly superior, and the popularity of Python should prove that people are OK with not having closing braces on their own lines: void foo(int x) { if(x == 0) { bar() }}

After having seen a meme, I gave a teacher a project formatted like this:

    public class Main                                        {
        public static void main(String[] args)               {
            System.out.println("Hello world!")             ;}}
We had a good laugh. (that was fine with him, of course as long as it's a joke)

PS: getting back to the original topic, imo, formatting style should be project-wide rules set at the beginning or during refactoring. Don't get too hung up on style as long as it stays consistent.

Re: Avoid Else, Return Early (2013)

#595

Post by WorldMaker »

sedachv wrote: post #590
WorldMaker wrote: post #588

Earlier quoted context omitted.

> Algorithmic complexity is not "moral superiority." The whole point of formal language theory is to show how the different languages differ in terms of how difficult they are to work with. Chomsky's hierarchy was designed for production from categories of languages. That it doubles as a useful rule of thumb for algorithmic complexity in parsing is a fascinating dualism in mathematics. That those same rules of thumb…

> This is also where it seems the clearest analogy lies to why I find your arguments to "complexity" so useless. Honestly, from everything you have posted so far, I really get the impression that you have never worked on programming language parsing, or with large code bases. The difference in algorithmic complexity is not "useless," it is the difference between being able to compile millions of lines of code in a fe…

Not saying algorithmic complexity is useless, only that it is a starting point in a discussion, not the end of the discussion. I've repeatedly used the analogy "tools in the toolbelt" as my return point in the discussion, so maybe you are missing plenty of my actual words in your "impression" that swings wildly toward an ad hominem attack.

If we want to fight anecdote for anecdote, I've certainly seen millions of lines of code of Python analyzed ("compiled") in seconds on modest hardware, rather than a cluster. Differences there are more in the static typing versus dynamic typing, and strongly compiled versus weakly compiled/primarily interpreted there. Maybe a better anecdote is millions of lines of Haskell? Seen that too. Whitespace-sensitive languages scale just fine.

I can understand it if you want to admit that you just don't like whitespace-sensitive languages for personal reasons, but there aren't very good technical reasons and you seem unhappy with my explanations of why that is the case. I'm not sure how much more I can try to explain it, and given you seem close to resorting to personal attacks I'm afraid this is likely where the conversation ends.

Re: Avoid Else, Return Early (2013)

#596

Post by crooked-v »

aiham wrote: post #528
crooked-v wrote: post #453

Earlier quoted context omitted.

And in Javascript, once do-expressions go from a proposal to a common part of the language, this will be a thing: let value = do {if (boolean) { this_value } else { other_value }} ...which is even closer to the Elixir style than JS's ternary operator (which is identical to Java's).

What's the advantage over JS's ternary operator?

The same pattern should be usable for things like switch statements.

Re: Avoid Else, Return Early (2013)

#597

Post by redblacktree »

collyw wrote: post #560
jcelerier wrote: post #302

Earlier quoted context omitted.

> Fewer LOC means more code on the screen, which means you can more easily grasp the functionality of some piece of code, uh ? for me the less code on each line and the easier it is to read

That depends. Python's pep guidelines has an 80 char wide rule, but I personally find that a lot harder to read than one long line (most of the time).

It's pretty sweet when you need to read code in a console that's limited to 80 characters. Also, it makes it easy to have two files opened side-by-side.

Re: Avoid Else, Return Early (2013)

#598

Post by arghwhat »

timoxley wrote: post #592
arghwhat wrote: post #564

Earlier quoted context omitted.

Quoting ECMA-262 First Edition (June 1997), Chapter 11, Section 11 (Binary logical operators)[1]: The production LogicalANDExpression : LogicalANDExpression && BitwiseORExpression is evaluated as follows: 1. Evaluate LogicalANDExpression. 2. Call GetValue(Result(1)). 3. Call ToBoolean(Result(2)). 4. If Result(3) is false, return Result(2). 5. Evaluate BitwiseORExpression. 6. Call GetValue((Result(5)). 7. Return Resul…

> the behavior has always been The ECMA spec only defines Javascript 1.3 and above. See this description for logical operators for Javascript 1.1: https://web.archive.org/web/20060318153542/wp.netscape.com/e...

ECMA-262 defines ECMAScript. "JavaScript 1.3" refers to a Netscape-specific language implementation ("Mocha", "LiveScript", "JavaScript"), with version 1.3 being based partially based on ECMA-262 Second Edition. Some of it might still live on in Firefox, but it is certainly not what people refer to as "JavaScript".

Doing some research, it appears that Netscape changed the logical operator behavior in version 1.2 (https://web.archive.org/web/19981202065738if_/http://develop...).

However, they did not highlight this change at all (https://web.archive.org/web/19970630092641fw_/http://develop...), so I suspect it was just a minor cleanup, potentially related to the equality operator change.

As a side-note: Netscape scripting was awful. This was how you casted an object to a Number:

    Number(x) = x;

Re: Avoid Else, Return Early (2013)

#599

Post by kazinator »

lokedhs wrote: post #591
jrimbault wrote: post #91

Earlier quoted context omitted.

>braces go on the end of the method/class name to reduce LOC You could argue the placement of braces with lots of valid arguments both way, but this... to reduce LOC ? Doesn't feel like a valid reason in any language using braces...

I've always wonder why no C or Java code formatter tool allows me to use Lisp-style formatting. It's clearly superior, and the popularity of Python should prove that people are OK with not having closing braces on their own lines: void foo(int x) { if(x == 0) { bar() }}

I've written a bit of code formatted rather like this:

    void foo(int x)
    { if(x == 0)
      { bar(); } }
That is workable. I have adhered to it (mostly) in this Yacc grammar file: http://www.kylheku.com/cgit/txr/tree/parser.y

Just in the grammar; not in the supporting functions.

It's an attractive style for C statements embedded in another language, because they look more like capsules somehow.

Re: Avoid Else, Return Early (2013)

#600

Post by skrebbel »

OvermindDL1 wrote: post #450
skrebbel wrote: post #283

This is why I'm so sad that Elixir doesn't have a return statement.

But Elixir 'does' have early returns, they are known as `Guards` as a language construct.

Yeah but that's only half the argument, right? Early returns make control flow a lot easier to read in general, not only when checking preconditions.
Post reply on HN