Re: how to make a macro work as a single line if stmt without braces

On 22/09/2024 05:05, Andrey Tarasevich wrote:

On 09/21/24 2:54 PM, Keith Thompson wrote:

>
One reason to "overuse" braces is that you can easily add another
statement.  If you write:
>
     if (failed)
          WARN("failed because...");
     else
          ok++;
>
and later decide you need two statements in the else clause, you then
need to add braces.  If they're already there, you don't.

 Adding braces in this situation is _incomparably_ easier than splitting an annoying single-line `if` statement into multiple lines, discovered during an interactive debugging session. Which is something you yourself described as "easy enough" below.

I don't think "incomparably" is the word you are looking for - especially while making a comparison!
Changes can always be made to code, and none of this is a particular challenge to do.

 

What you call "Egyptian" braces is the style used by the creators of the
language

 Firstly, this is style. Being a "creator of the language" does not make one an authority on code formatting style.
 

Agreed.

Secondly, most people pick up "the style used by the creators of the language" from the code samples used in the 2nd edition of K&R book. And, as we know, "the creators of the language" went a little lazy here. The samples were considered of "low importance" and fell victim to the tightening publishing schedules in front of the looming "threat" of the upcoming ANSI standard. The code samples were never properly updated to match the style and spirit of modern C.
 

I can't speak for anyone else, but it is certainly not why I use this style.  I have tried a few styles, I have seen many more, and it was a conscious decision about what I think makes code clearer to read and has the minimal risk of errors or misunderstandings.

This is BTW, the reason we have to deal with that pesky and atrocious manner to cast the result of `malloc` - another practice erroneously believed to be "the style used by the creators of the language".

There are plenty of design decisions in C that some people will think were a good idea, and others think are a bad idea.  Let's not go there!

 

and in a *lot* of open source software.  Even if you don't like
the style, you'll need to deal with it.
I have my own fairly strong preferences about brace placement, but the
most important rule is to follow the conventions of the code I'm working
on.

 

Agreed.
There's nothing worse than a git/subversion/whatever checkin when someone has changed the entire file to move around some braces or convert between their preferences of tabs or spaces.[1]

Certainly. It is not a good practice to force your own style onto someone else's code or an already existing code. Still, in most reasonably organized professional development environments personal preferences are normally welcomed with certain granularity. It is usually organized on "per translation unit" basis.
 

Practices vary somewhat.  And while there's a fair variety of styles that can be seen as reasonable enough, it sometimes happens that the new person in a team has such a terrible style that they are forced to change.
[1] Except, of course, a paper-cut.  It's a well-established fact that there is nothing worse than a paper-cut!