Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That pattern still seems like obfuscation to me. Why not indent the inner for loop, to make the control flow more obvious?

For instance, consider how "break" or "continue" inside the braces would work.



The reason for doing it that way, is to emphasize when two loops together are conceptually iterating over a single thing, and have some symmetry, like iterating over the cells in a 2D grid. It makes it possible to line up the elements of the two loops, emphasizing the similar structure.

I agree that it would be very bad form to use "break" inside a block like that. But in the cases where this construct applies, it would still be bad form to break if the outer block had curly braces and indentation, because skipping the rest of a row isn't a natural operation in the sort of way that skipping the rest of a collection is.


Even with that explanation I am not convinced of the soundness of that notation. For example, if you think you have a particular row that is causing you some problem and want to add a print statement for the row number, your code becomes, if you are too quick and forget to add braces:

    for(y=0; y<ymax; y++)
    printf("y=%i\n",y);
    for(x=0; x<xmax; x++)
    {
        //...
    }
And it will not work anymore as intended.

Granted it's a small mistake and it will not take more than 5 minutes to fix, but it still add a small load to your already busy mind.


This doesn't seem like a realistic mistake to me. The printf is just at the wrong indent level; this is the same mistake as:

    for(i=0; i<imax; i++)
    printf("i=%i\n",i)
    {
        //...
    }
Which also compiles and which is wrong in the same way. I don't recall ever having made or having seen this.


Well, not really, because in the example you just gave, you would put the printf right between the braces as it should be. In the case originally discussed, you have no braces so you would have to add them, and that can be forgotten.


Totally agreed, but in this case if the author had declared the variable in the for-loop:

  for(int y=0; y < ymax; y++) 
     ...
and didn't shadow y from an enclosing scope, that would have given the compiler a chance to catch that error.


If the option is between "something we personally like but has edge cases or requires other understanding that could confuse some readers" versus "something everybody will understand," the first case should never happen.

It's almost like everybody forgot about https://matt.sh/howto-c#_formatting already. :(


However one can say they are not quite the same thing, as you mentioned, how "break"s work, so it is obfuscating things a bit. But even performance wise: in order in which you iterate over the arrays can make a significant difference because of cache effects. So it is important to make obvious which one is the nested loop and which one is the outer one.


> The reason for doing it that way, is to emphasize when two loops together are conceptually iterating over a single thing, and have some symmetry, like iterating over the cells in a 2D grid. It makes it possible to line up the elements of the two loops, emphasizing the similar structure.

I'm not convinced. Even iterating over a 2D grid, one loop is iterating over the columns, and the other the rows, and indentation (and braces) can help see which is which.


I don't see how 'continue' would be confusing, it would stop the current calculation and start the next one, same as with normal loops.

The behaviour of 'break' might be confusing but then that's always the case in nested loops, no matter how you notate them.


I would argue that `break` intuitively makes you go back an indent, so if you don't indent after the first `for`, one can assume `break` just exits both loops (goes back from lvl 1 to lvl 0 indent)


This doesn't quite work, since break skips over if statements (and most breaks have at least one if statement around them). So you have to look glance at the keyword at the elbow of each indent anyways, to know where it's going.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: