5 ms·

Reading code from top to bottom (1999)

47 points by julietteeb 4y ago

dang 4y ago
Related: Tom Duff: Reading Code From Top to Bottom (1999) - https://news.ycombinator.com/item?id=2620872 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.
- pvg 4y ago
  There are several references to the time of writing in the piece, each with a date and the last one is Yesterday (Feb 21, 1999) I rewrote [...]
saila 4y ago
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.
- dgb23 4y ago
  To me early returns and top level exceptions are nice to convey base cases, invariants, short cuts etc. nested branching to convey choice that is more closely related. The former is often not possible (or idiomatic) in expression based languages however.
- mbrodersen 4y ago
  Agree. I always code that way (in non-functional languages).
engmgrmgr 4y ago
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.
stitched2gethr 4y ago
This is how the Go community recommends you write Go code. It is pleasant.
_8j50 4y ago
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.
froh 4y ago
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%20programming%20with%20GOTO%20statements&publication_year=1974&author=D.E.%20Knuth 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&query=Structured%20programming%20with%20goto%20statements&sort=byPopularity&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
cehrlich 4y ago
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.
Mawr 4y ago
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.
unwind 4y ago
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.
svilen_dobrev 4y ago
i call that get-out-as-fast-as-u-know-the-decision style a "die now without agony".
potiuper 4y ago
If speed is deciding factor, then cases have to be written in descending order of likelihood.

47 points by julietteeb 4y ago

dang 4y ago

Related: Tom Duff: Reading Code From Top to Bottom (1999) - https://news.ycombinator.com/item?id=2620872 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.

pvg 4y ago
There are several references to the time of writing in the piece, each with a date and the last one is Yesterday (Feb 21, 1999) I rewrote [...]

saila 4y ago

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.

dgb23 4y ago
To me early returns and top level exceptions are nice to convey base cases, invariants, short cuts etc. nested branching to convey choice that is more closely related. The former is often not possible (or idiomatic) in expression based languages however.
mbrodersen 4y ago
Agree. I always code that way (in non-functional languages).

engmgrmgr 4y ago

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.

stitched2gethr 4y ago

This is how the Go community recommends you write Go code. It is pleasant.

_8j50 4y ago

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.

froh 4y ago

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%20programming%20with%20GOTO%20statements&publication_year=1974&author=D.E.%20Knuth 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&query=Structured%20programming%20with%20goto%20statements&sort=byPopularity&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

cehrlich 4y ago

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.

Mawr 4y ago

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.

unwind 4y ago

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.

svilen_dobrev 4y ago

i call that get-out-as-fast-as-u-know-the-decision style a "die now without agony".

potiuper 4y ago

If speed is deciding factor, then cases have to be written in descending order of likelihood.