from Hacker News

Reading code from top to bottom (1999)

by julietteeb on 4/3/22, 2:43 PM with 14 comments

by saila on 4/4/22, 2:19 AM

I prefer code in this style too:

    if something:
        return something
    if something else:
        return something else
    return default

It's not applicable everywhere, but where it is, it seems tidier to me than the alternative:

    if something:
        return something
    elif something else:
        return something else
    else:
        return default

Edit: The article basically says the same thing. I just had a hard time parsing all that C at first.

by dang on 4/4/22, 1:13 AM
Related:
Tom Duff: Reading Code From Top to Bottom (1999) - https://news.ycombinator.com/item?id=2620872 - June 2011 (22 comments)
Not sure how the 1999 ended up there but it looks plausible enough so I'll copy it.
by cehrlich on 4/4/22, 6:20 AM
I like the 'guard clauses that return 0 etc at the top, "real" return at the bottom' style in general, but I find it important to be careful that it doesn't degenerate into 'returns in the top, middle, and bottom', which isn't any better than the thing we were trying to avoid in the first place.
Similar thing with avoiding nesting and else clauses - generally a good idea, but occasionally they're the right choice, so better not to be dogmatic about it.
by froh on 4/4/22, 6:18 AM
Tom Duff at the end is referring to a very nuanced kind of response of Knuth to Dijkstra from 1974, like so:
> The best reference on programming in a disciplined way using goto is still D. E. Knuth's paper Structured Programming with go to Statements, ACM Computing Surveys, Vol. 6, No. 4, December 1974, pp. 261-302. I think that everything I have to say about goto is in his paper.
https://scholar.google.com/scholar_lookup?title=Structured%2...
It has received only very little discussion here on HN
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
by stitched2gethr on 4/4/22, 4:13 AM
This is how the Go community recommends you write Go code. It is pleasant.
by potiuper on 4/4/22, 12:57 PM
If speed is deciding factor, then cases have to be written in descending order of likelihood.
by engmgrmgr on 4/4/22, 3:36 AM
WDYT about initializing a limit and having only one return? For/else in some languages is kind of interesting, too.
I’m indifferent in practice (whatever’s readable to others is usually best), but I like the limit approach in theory.
by badrabbit on 4/4/22, 4:28 AM
I like bottom to top as well. I just dislike <random location in the middle> and then you scroll around trying to figure out context.
by svilen_dobrev on 4/4/22, 11:06 AM
i call that get-out-as-fast-as-u-know-the-decision style a "die now without agony".
by unwind on 4/4/22, 8:02 AM
My observations, as an opinionated C programmer:
1. Missing const; always const all the things, especially pointers passed to functions. Semantically a "find" would be a read-only operation, to me it's a huge red flag if it's not const-declared.
2. Why NULL-check the array but not the name? I guess it doesn't affect functionality, or perhaps NULL is a valid name. Confusing without more context/commentary.
3. I prefer "++i" rather than "i++" in for loops like this because of reasons, but that's a rather minor point of course.
4. Be daring and use at least C99, move the "int i" to the for-loop's initializing part.
5. It's not obvious that the comparison doesn't need strcmp(), but might be clear from context, would expect comment to clarify that.
I agree with the top-down rewrite and find the revised code better, it's just not ... good enough yet. :)
Edit: list formatting.

by Mawr on 4/4/22, 7:41 AM

1. Missing spaces around operators like "==". The first code example has them, but the author proceeds to remove them with no mention as to why.

2. More than one statement on a line:

    int f(int x){
        int v;

        if(b(x)) v=f1(x);
        else v=f2(x);
        return v;
    }

This is so much harder to read than:

    int f(int x){
        int v;
    
        if(b(x)) {
            v=f1(x);
        }else{
            v=f2(x);
        }
        return v;
    }

3. Control flow statements placed arbitrarily far down a line:

    int f(int x){
        if(b(x)) return f1(x);
        return f2(x);
    }

Always keep them at the start of lines:

    int f(int x){
        if(b(x))
            return f1(x);
        return f2(x);
    }

4. Nested ternary operators, yikes:

    int a(int i, int j){
        return i?a(i-1, j?a(i, j-1):1):j+1;
    }

    The language I'm testing is missing the ?: conditional expression, so I had to reword function a using ordinary if statements.

    int a(int i, int j){
        if(i==0) return j+1;
        if(j==0) return a(i-1, 1);
        return a(i-1, a(i, j-1));
    }

    Much better.

It's scary that the author only rewrote this due to a language limitation. The original is painful to read.