There's always been the debate about omitting braces for single line if's and loops, but today I learned the C compiler actually allows you to do this:

for (i = 0; i < x; i++)
for (j = 0; j < y; j++) {
do_something(i, j);
something_else();
}

Yes of course - the second block is a single block.

Btw., "devrant" doesn't mean "developer rant" because there are only devs here. No finance, HR, or sales rants. It means "stuff about devrant.com itself."

@Fast-Nop Oh wow, I indeed failed to recognize the huge red "Rant / Story" button as a category by itself. So much for intuitive UX design...

The code just looks more weird when correctly indented, i.e. you have a block ending with a brace that is indented, but there's a weird visual gap where you would expect the closing brace.

Well, devrant was never designed for including code blocks.

@ninjasloth Yeah, that weird, hacked-off look is why I use braces in that case even in code bases that don't have mandatory braces anyway.

I mean, it's right and all, but I will find you, and I slap you with that missing brace.

It's bad enough when you have code blocks defined as

func this():
// some logic goes in here
end;

If this thing works, then you don't need to worry about it.

@highlight
// Sanka, you dead man?

What is wrong with spending the extra 1 second to add { } ?

It makes code more readable imo

This is one of the reasons should not use this horrible indention style and always use {}. Using this indention style and not using {} everywhere creates a opportunity to forget a { in one place and a } in a different place so that you end up with valid code that does not work.

@happygimp0 horrible?
what, this is better ?

this()
{

// do something in this wasted space
// down here?
}

@C0D4 The opening { and closing } should always be on either the same column or line, they belong together and you should see immediately where they start and end. Also the compiler starts a block at { and ends the block at }, your indention style should reflect that.

Other styles had some advantages 30 years ago when space was expensive and monitors where small, but today you should choose the most readable style.

@happygimp0 I've always found it easier to follow with down the screen with

This() {

}

As you read the function name and scan for its closing } downwards, but each to their own 🤷‍♂️

@happygimp0 the main reason you add the opening bracket on the end of the line is that you can not accidentally inject a line in between and cause the block to be orphaned.

Since an orphaned block is still valid code it could slip by and cause logical errors in runtime.

Adding the opening in the end makes that much less likely.

And thats also why the recommendation was to always have the brackets, adding another line to the single line scope would be trivial.

Now, personally I do break this rule depending on the context but I remember reading multiple guidelines about it.

@C0D4 Again, the compiler starts at the { with the block. Secondly it is easy to forget { when you put it at the end. The { and } build a pair, it makes no sense to not start at the { and search for the }.

}}

@Voxera I never saw a single error where a person did put text before the line with the { when they wanted to add something to a block, in the other hand i saw many errors where someone, especially beginners, forgot a { or }.

}

How to fill the bottom right square in a way that is readable, simple and reflects what the compiler does?

@happygimp0 With the Egyptian braces, you look vertically from the indentation, not diagonally from the opening brace. Also, you can see more lines per screen. That said, I still don't like them.

@happygimp0 the compiler can shove it all on 1 line for all I care, that doesn't mean it's logical.

blocks that are easy to scan through rather then chase indentation around make sense.

Your example neglects the fact that it's often many lines within the if() and else and not 1 liners.

What's odd with that snippet at all?

@C0D4 The compiler does what is logical. The logical block starts at {. C is not Python, the indention does not matter for the logic. To be fair, Python syntax is much better (i hate that rust didn't adopt it).

The Egyptian style does not get better when there are more lines. If you think that: Show me a diagram like i did where Egyptian style makes sense. I am really curios, there is a lot of code i can't read because of its indention style.

}

@Fast-Nop The logical block starts at the {. This is just how C syntax work. In other programming languages where you can look at the indention. But in C you have to start at the { .

}}

@happygimp0 When I'm in code bases with that brace style, I don't look diagonally. I'm not a compiler, after all.

@happygimp0 it's hard to explain in text, plus I'm on my phone so can't exactly draw it 😂 or can I....

I don't read from the the opening {

I read from the start of the line and work downwards. Making indentation important.

Having the open brace on the same line makes life easier and as @voxera said, prevents simple mistakes.

One liners without braces I also dislike as it's easy to add logic to there's and miss the braces completely causing issues of your own.

So, back to this:

...

The code where I found this gem looked like this (I guess screenshots are required here as no other formatting is available), no idea though why they even used double indentation just for the inner loop.

Actually, after the initial confusion this does not even look just as bad as I remebered it, but the missing brace is still kind of weird...

@ninjasloth Yeah, why write it like that ?

One small mistake like adding something right after the last } and you have a bug (depending on what you want :) )

On legacy code, I often see this :

if x=y

--Dothis

if e=p

--Dothis

It is nice and less space, but dangerous if you need to add something in between.

@happygimp0 I have not seen that either and as I said I do mot follow it, especially since I use c# and visual studio has { on its own line by default.

But I have read arguments that at least early on diff could cause lines to be inserted wrong.

But its just hearsay in my case.

If you do nested stuff that way, put the second for on the same line after the first for and indent the braced block once. Then the indenting doesn't look off.

But normally, just bracing the outer for too still is the better option...

@happygimp0 in the bottom example the curly brackets are still aligned, but they're aligned with the block identifier (int foo, if, etc...)

Same way there are no `if else` in C, it's really just another if block as the single statement for the else.

@C0D4

"I don't read from the the opening {"

But the compiler does. You should start where the compiler starts to avoid errors. You wont detect a missing {.

"Making indentation important."

But the compiler ignores it. You can, and should, do it in languages like Python.

"Having the open brace on the same line makes life easier and as @voxera said, prevents simple mistakes."

Not seen that error once in my life, but saw a lot of people that missed a { or } somewhere.

@crisz Again: The block starts at { not where you start the indentation. You have to check and make sure { and } are both there, otherwise you can generate valid code that is wrong because the blocks don't start and end where you think they are.

@happygimp0 never happened a similar case in 8+ year of programming. Usually IDE highlight matching brackets, you format and prettify the code, and in general someone is supposed to always properly indent the code

@crisz I saw a lot of beginners doing that error.