4 ms·

Keep in mind they're not always equivalent. If you have 'continue' in the middle then the for loop will still perform the increment but the while loop won't.

google234123 5y ago
This bites me a few times a year.
- dataflow 5y ago
  IMHO the way to avoid it is to avoid nonlinear [1] control flow. If you can convince yourself that early returns, continue, etc. are harmful, you'll avoid the pitfalls that come with them. It's an unpopular position to take, though. [1] I might be sloppy with the terminology here, but you catch my drift.
  - jraph 5y ago
    I do think early returns, continue, etc are a good source of clarity. Sometimes, code that avoids early returns seems convoluted and can use more variables, be more verbose and require more effort to be understood. In for loops, you need to understand that this complicated condition is there to replace a break. Not my cup of tea.
    - dataflow 5y ago
      Yeah I get that, that's always the argument. I'm not an absolutist on this either (I do sprinkle continue/return into my code once in a while when it really seems worth it; even the same with the occasional goto), but in general I feel people are way more liberal with these than they should be (except goto, which people avoid at all costs no matter how complicated the code becomes, thus erring toward the other extreme). Never been able to convince many others though; the arguments never get anywhere when person A insists X is more readable and person B insists Y is more readable.
      - jraph 5y ago
        At the end, readability depends heavily on habits. You can know that, but you feel it when you work on various codebases with different people / switch teams. So, yes. Nobody is right or wrong in these topics. Moreover, there are situations where one is clearly better than the other. If you need to (formally) verify your code, depending on the method, maybe early returns are to be avoided.
      - avar 5y ago
        The use of "goto" is fine and more legible in some contexts, such as jumping to the "cleanup" part of a function. You can avoid it, but it'll involve one of repetition, a wrapper function, or "formalizing" the cleanup so that it's your only cleanup call. Depending on the situation those are all going to be way more verbose. Some advanced use cases include jumping between "case" labels, or jumping into the middle of a loop. Most of the time that's bad practice, but in the cases that benefit from them it's much better than the alternatives.
- andai 5y ago
  Here's a thought: some languages have a defer statement that runs when the function is exited. This allows for cleanup code to run even with early return. Perhaps a block-level defer could be useful: int i = 0; while (i < 10) { defer i++; // ... continue; // ... }
  - AlbertoGP 5y ago
    If someone wants to play with this idea, I made a pre-processor that translates that into standard C, inserting the deferred statements at each exit point (break, continue, goto, return, end of block): https://news.ycombinator.com/item?id=28166125 https://news.ycombinator.com/item?id=28166125 https://sentido-labs.com/en/library/cedro/202106171400/#deferred-resource-release https://sentido-labs.com/en/library/cedro/202106171400/#defe...
    - andai 5y ago
      Hahah, what are the odds! Thanks for sharing, I will take a look.

google234123 5y ago

This bites me a few times a year.

dataflow 5y ago
IMHO the way to avoid it is to avoid nonlinear [1] control flow. If you can convince yourself that early returns, continue, etc. are harmful, you'll avoid the pitfalls that come with them. It's an unpopular position to take, though. [1] I might be sloppy with the terminology here, but you catch my drift.
- jraph 5y ago
  I do think early returns, continue, etc are a good source of clarity. Sometimes, code that avoids early returns seems convoluted and can use more variables, be more verbose and require more effort to be understood. In for loops, you need to understand that this complicated condition is there to replace a break. Not my cup of tea.
  - dataflow 5y ago
    Yeah I get that, that's always the argument. I'm not an absolutist on this either (I do sprinkle continue/return into my code once in a while when it really seems worth it; even the same with the occasional goto), but in general I feel people are way more liberal with these than they should be (except goto, which people avoid at all costs no matter how complicated the code becomes, thus erring toward the other extreme). Never been able to convince many others though; the arguments never get anywhere when person A insists X is more readable and person B insists Y is more readable.
    - jraph 5y ago
      At the end, readability depends heavily on habits. You can know that, but you feel it when you work on various codebases with different people / switch teams. So, yes. Nobody is right or wrong in these topics. Moreover, there are situations where one is clearly better than the other. If you need to (formally) verify your code, depending on the method, maybe early returns are to be avoided.
    - avar 5y ago
      The use of "goto" is fine and more legible in some contexts, such as jumping to the "cleanup" part of a function. You can avoid it, but it'll involve one of repetition, a wrapper function, or "formalizing" the cleanup so that it's your only cleanup call. Depending on the situation those are all going to be way more verbose. Some advanced use cases include jumping between "case" labels, or jumping into the middle of a loop. Most of the time that's bad practice, but in the cases that benefit from them it's much better than the alternatives.
andai 5y ago
Here's a thought: some languages have a defer statement that runs when the function is exited. This allows for cleanup code to run even with early return. Perhaps a block-level defer could be useful: int i = 0; while (i < 10) { defer i++; // ... continue; // ... }
- AlbertoGP 5y ago
  If someone wants to play with this idea, I made a pre-processor that translates that into standard C, inserting the deferred statements at each exit point (break, continue, goto, return, end of block): https://news.ycombinator.com/item?id=28166125 https://news.ycombinator.com/item?id=28166125 https://sentido-labs.com/en/library/cedro/202106171400/#deferred-resource-release https://sentido-labs.com/en/library/cedro/202106171400/#defe...
  - andai 5y ago
    Hahah, what are the odds! Thanks for sharing, I will take a look.