4 ms·

"8. You have early exits from loops because you don't know how to properly code a recursion." Wow. Not every problem calls for recursion. If you really hate e

by boucher 19y ago

"8. You have early exits from loops because you don't know how to properly code a recursion." Wow. Not every problem calls for recursion. If you really hate early exits from loops, maybe you should just code the loop's condition differently.

edw519 19y ago
"If you really hate early exits from loops, maybe you should just code the loop's condition differently." Exactly. Like I mentioned before, I'm the poor schmuck that has to clean it up because someone didn't bother to take your (common sense) advice years ago.
- boucher 19y ago
  Sometimes it makes more sense to bail early than it would to restructure. It could be that its more readable, or a more natural progression of things. Take this paper: http://www.csd.uwo.ca/~yuri/Papers/pami04.pdf http://www.csd.uwo.ca/~yuri/Papers/pami04.pdf It's really great, for the record. Anyway, the algorithm they wrote uses an early exit. In fact, they use a while(true), the "worst case" example. initialize: S = {s}, T = {t}, A = {s, t}, O = {(Empty Set)} while true grow S or T to find an augmenting path P from s to t if P = {(Empty Set)} terminate augment on P adopt orphans end while In programming this algorithm, sure, I could probably move the first grow before the loop, and grow at the end. But, now its harder to understand, and violates the afore mentioned copy paste rule. My point is this, take any such "rule" with a grain of salt. There are plenty of examples where it makes sense to do something atypical.
  - edw519 19y ago
    "violates the afore mentioned copy paste rule" Put it in a common function. Sure, it may look a little frazzled today, but generations of future hackers will thank you.
    - boucher 19y ago
      You're still making two function calls when you could be making one. If one of them gets lost in the fray, you'll spend just as much time solving that problem.
      - Goladus 19y ago
        Are the costs of function call overhead worth worrying about?
        edw519 19y ago
        Maybe this is the crux of Dijkstra's original arguments. Which is more expensive, a few milliseconds of machine time a few million times or a whole bunch of human time once or twice?
        boucher 19y ago
        Not at all. What I meant was, you're calling the function in two places, instead of in one place (inside the loop). You've pasted that function call. Thus, by all the same logic, you are introducing a possible future headache.
      - akkartik 19y ago
        One very useful idiom: while(readLine()) { process lines... } where readLine() encapsulates the repetition and returns eof as well.
        mwerty 19y ago
        where is the line (to be processed) stored?
        akkartik 19y ago
        In my comment I assumed it's a line in a file and that the termination condition is eof, but you can generalize to any aggregate of items. I'm just combining the test with the increment step so we can use a simple while loop without having to peel the 'first increment' step out of the loop. If that makes any sense :)

by boucher 19y ago

edw519 19y ago

"If you really hate early exits from loops, maybe you should just code the loop's condition differently." Exactly. Like I mentioned before, I'm the poor schmuck that has to clean it up because someone didn't bother to take your (common sense) advice years ago.

boucher 19y ago
Sometimes it makes more sense to bail early than it would to restructure. It could be that its more readable, or a more natural progression of things. Take this paper: http://www.csd.uwo.ca/~yuri/Papers/pami04.pdf http://www.csd.uwo.ca/~yuri/Papers/pami04.pdf It's really great, for the record. Anyway, the algorithm they wrote uses an early exit. In fact, they use a while(true), the "worst case" example. initialize: S = {s}, T = {t}, A = {s, t}, O = {(Empty Set)} while true grow S or T to find an augmenting path P from s to t if P = {(Empty Set)} terminate augment on P adopt orphans end while In programming this algorithm, sure, I could probably move the first grow before the loop, and grow at the end. But, now its harder to understand, and violates the afore mentioned copy paste rule. My point is this, take any such "rule" with a grain of salt. There are plenty of examples where it makes sense to do something atypical.
- edw519 19y ago
  "violates the afore mentioned copy paste rule" Put it in a common function. Sure, it may look a little frazzled today, but generations of future hackers will thank you.
  - boucher 19y ago
    You're still making two function calls when you could be making one. If one of them gets lost in the fray, you'll spend just as much time solving that problem.
    - Goladus 19y ago
      Are the costs of function call overhead worth worrying about?
      - edw519 19y ago
        Maybe this is the crux of Dijkstra's original arguments. Which is more expensive, a few milliseconds of machine time a few million times or a whole bunch of human time once or twice?
      - boucher 19y ago
        Not at all. What I meant was, you're calling the function in two places, instead of in one place (inside the loop). You've pasted that function call. Thus, by all the same logic, you are introducing a possible future headache.
    - akkartik 19y ago
      One very useful idiom: while(readLine()) { process lines... } where readLine() encapsulates the repetition and returns eof as well.
      - mwerty 19y ago
        where is the line (to be processed) stored?
        akkartik 19y ago
        In my comment I assumed it's a line in a file and that the termination condition is eof, but you can generalize to any aggregate of items. I'm just combining the test with the increment step so we can use a simple while loop without having to peel the 'first increment' step out of the loop. If that makes any sense :)