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

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

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.

Perhaps I don't use interactive debuggers as much as other programmers
do, but I certainly haven't found it terribly difficult to temporarily
reformat code as needed (not that I've run into that particular issue
very often).  I'm likely to be modifying and rebuilding the software
anyway.

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.

True.

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.

You seem to be asserting that K&R-style brace placement goes against
"the style and spirit of modern C".  In my opinion and experience, it
absolutely does not.

You prefer braces on their own lines.  I prefer to put opening braces at
the end of the line.  Neither of us is objectively right or wrong.

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".
 

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.

>
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.

That's not my experience at all.  In some environments, there's a
project-wide written coding standard (which may or may not be strictly
followed).  In others, the style is (ideally) consistent at least across
each project or subproject.

I suppose I could deal with a project where each translation unit has
its own style, but thankfully I've never had to.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */