2
Mirinum
5y

I've always was curious why people debating about mostly two code formatting types
for(;;)
{
//somestuff
}
or
for(;;){
//somestuff
}
while almost no one uses pretty decent IMO type like
for(;;){
//somestuff
//somemorestuff} (with tabs ofc)

It might be easier to forget some }s, but other than that it seems pretty nice to me

Comments
  • 3
    No. Curlies and semis should always start at column 128. Easy to scan down the line to see what you're missing, and if you're lucky, the computer will forget about them and stop complaining/erroring because they're so far away from the code.
  • 6
    Did you just put that curly on the same line as that other line of code?

    Don't make me come to... I'm guessing Ukraine?... and force that curly somewhere you may, or may not enjoy.

    That curly belongs on its own, as it's used to signify an end of block, a block should always end at the same place it started, A) for quick readability and B) so code editors can actually work out where on this massive ass code base that open curly actually closes.
  • 1
    I've always preferred the symmetry and readability of block boundaries on their own line aligned vertically. Going all the way back to Fortran 77.
  • 2
    Use whatever you and your team can agree on. Just make sure to stay consistent
  • 2
    for(;;){something;something;something;}
    your langs are supposedly superior due to being able to do that, so fucking do it xD

    (sorry, C0D4, rogue @...)
  • 2
    @Parzi i was so confused for a moment there.
  • 1
    You can use whatever you and your team chooses but the advocates of the
    If (x>5) {
    //do stuff
    }

    Usually use the motivation that it allows for arbitrary line insertion without changing existing code scope.

    Since, at least in C# the following is valid code

    If(x>5)
    DoSimethingOther();
    {
    //do stuff
    }

    You cannot insert a new line at will.

    The later code no longer conditions the do stuff.

    With the original syntax the new line could not break apart the if.

    But that was more useful before modern ide’s

    Also its more used in languages with less strict syntax.

    I prefer the second in c# and the first in js.
  • 4
    To end the discussion once and for all, I hereby declare that from now on the curly braces have to be on a line of its own and to instantly identify each indentation level, the number of curly braces has to match the indentation level.

    Howgh, I have spoken.
  • 1
    @Voxera I don't know why invading a block like that is considered a pro anyway. In C you can have this

    if (spinach == good);
    {
    destruct_world();
    }

    That will destruct the world even if spinach is not good, as ';' is an empty statement.

    I actually spotted a very old bug like this in production code because the compiler threw a warning and everyone had missed that. It had never caused any problems though.
  • 0
    @Voxera wow, thanks, that's interesting, I didn't know you can do it in C#. That kinda makes sense
  • 1
    @ddephor

    xD seems reasonable to me
  • 0
    @electrineer my point was not actually to endorse any one and I use both.

    The idea of using { at the end of the line is to prevent for example merges from inserting a line in a way that breaks code.

    I don’t think it should be a problem as long as any conflicts are actually checked, not just forced ;)

    And your example would most likely not just happen like that and as you say, such things are often spotted by compiler or linter so its in my opinion more important to keep “one” standard than one “specific” standard :)
  • 1
    @Mirinum yes you can have free standing blocks.

    Its most likely not a good idea since it probably is used to get local variable scopes, which indicates the method should be broken up in parts.

    But I am sure there is at least one good use case somewhere :)

    I do use such in one place, within switch statements where I might want to reuse a variable name without having to move declaration to the top.

    And yes, those should probably be broken into individual functions per case but its within an interpreter for a script engine and there are many very small cases, using function would increase code size by 30 % and actually be less readable and keeping all in one gives me some dirty but efficient short cuts that improves performance enough to be worth it :)

    There might be a even better way, but rewriting is not motivated as the code almost never changes now that its done :)
Add Comment