Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #388454 > unrolled thread

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

Back to article view | Back to comp.lang.c

Contents

  how to make a macro work as a single line if stmt without braces Mark Summerfield <mark@qtrac.eu> - 2024-09-21 07:35 +0000
    Re: how to make a macro work as a single line if stmt without braces Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-09-21 08:10 +0000
    Re: how to make a macro work as a single line if stmt without braces David Brown <david.brown@hesbynett.no> - 2024-09-21 10:47 +0200
      Re: how to make a macro work as a single line if stmt without braces Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-09-21 12:27 -0700
        Re: how to make a macro work as a single line if stmt without braces Bart <bc@freeuk.com> - 2024-09-21 21:11 +0100
        Re: how to make a macro work as a single line if stmt without braces Opus <ifonly@youknew.org> - 2024-09-21 22:39 +0200
        Re: how to make a macro work as a single line if stmt without braces Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-21 14:54 -0700
          Re: how to make a macro work as a single line if stmt without braces Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-09-21 20:05 -0700
            Re: how to make a macro work as a single line if stmt without braces Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-21 21:33 -0700
            Re: how to make a macro work as a single line if stmt without braces David Brown <david.brown@hesbynett.no> - 2024-09-22 14:15 +0200
            Re: how to make a macro work as a single line if stmt without braces Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-27 03:38 -0700
        Re: how to make a macro work as a single line if stmt without braces David Brown <david.brown@hesbynett.no> - 2024-09-22 13:59 +0200
          Re: how to make a macro work as a single line if stmt without braces Kaz Kylheku <643-408-1753@kylheku.com> - 2024-09-22 15:11 +0000
            Re: how to make a macro work as a single line if stmt without braces Bart <bc@freeuk.com> - 2024-09-22 16:56 +0100
              Re: how to make a macro work as a single line if stmt without braces Michael S <already5chosen@yahoo.com> - 2024-09-22 19:27 +0300
                Re: how to make a macro work as a single line if stmt without braces Bart <bc@freeuk.com> - 2024-09-22 17:47 +0100
                Re: how to make a macro work as a single line if stmt without braces Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-24 07:36 -0700
                  Re: how to make a macro work as a single line if stmt without braces Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-09-24 07:52 -0700
                    Re: how to make a macro work as a single line if stmt without braces David Brown <david.brown@hesbynett.no> - 2024-09-24 17:24 +0200
                    Re: how to make a macro work as a single line if stmt without braces Bart <bc@freeuk.com> - 2024-09-24 17:22 +0100
                      Re: how to make a macro work as a single line if stmt without braces Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-24 12:28 -0700
                    Re: how to make a macro work as a single line if stmt without braces Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-27 01:43 -0700
                  Re: how to make a macro work as a single line if stmt without braces Bart <bc@freeuk.com> - 2024-09-24 17:35 +0100
                    Re: how to make a macro work as a single line if stmt without braces Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-24 12:30 -0700
                      Re: how to make a macro work as a single line if stmt without braces Bart <bc@freeuk.com> - 2024-09-24 20:42 +0100
                    Re: how to make a macro work as a single line if stmt without braces Kaz Kylheku <643-408-1753@kylheku.com> - 2024-09-24 19:59 +0000
                      Re: how to make a macro work as a single line if stmt without braces Bart <bc@freeuk.com> - 2024-09-24 21:12 +0100
                        Re: how to make a macro work as a single line if stmt without braces Kaz Kylheku <643-408-1753@kylheku.com> - 2024-09-24 22:36 +0000
              Re: how to make a macro work as a single line if stmt without braces Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-22 13:39 -0700
                Re: how to make a macro work as a single line if stmt without braces David Brown <david.brown@hesbynett.no> - 2024-09-23 08:16 +0200
                  Re: how to make a macro work as a single line if stmt without braces Richard Harnden <richard.nospam@gmail.invalid> - 2024-09-23 08:06 +0100
                    Re: how to make a macro work as a single line if stmt without braces David Brown <david.brown@hesbynett.no> - 2024-09-23 11:14 +0200
                      Re: how to make a macro work as a single line if stmt without braces Richard Harnden <richard.nospam@gmail.invalid> - 2024-09-23 11:37 +0100
                        Re: how to make a macro work as a single line if stmt without braces David Brown <david.brown@hesbynett.no> - 2024-09-23 14:22 +0200
            Modern text editor - 'bout time someone paid attention to keeping the thread title relevant!!! (Was: how to make a macro work as a single line if stmt without braces) gazelle@shell.xmission.com (Kenny McCormack) - 2024-09-22 16:03 +0000
            Re: how to make a macro work as a single line if stmt without braces David Brown <david.brown@hesbynett.no> - 2024-09-22 18:03 +0200
        Re: how to make a macro work as a single line if stmt without braces Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-28 05:02 -0700
          Re: how to make a macro work as a single line if stmt without braces Michael S <already5chosen@yahoo.com> - 2024-09-28 20:30 +0300
            Re: how to make a macro work as a single line if stmt without braces Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-28 21:53 -0700
              Re: how to make a macro work as a single line if stmt without braces Michael S <already5chosen@yahoo.com> - 2024-09-29 12:48 +0300
                Re: how to make a macro work as a single line if stmt without braces Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-29 19:18 -0700
                Re: how to make a macro work as a single line if stmt without braces Alan Mackenzie <acm@muc.de> - 2024-09-30 15:05 +0000
          Re: how to make a macro work as a single line if stmt without braces Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-09-28 21:02 -0700
            Re: how to make a macro work as a single line if stmt without braces Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-28 22:47 -0700
              Re: how to make a macro work as a single line if stmt without braces Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-09-29 07:41 -0700
                Re: how to make a macro work as a single line if stmt without braces Michael S <already5chosen@yahoo.com> - 2024-09-29 18:04 +0300
                Re: how to make a macro work as a single line if stmt without braces scott@slp53.sl.home (Scott Lurndal) - 2024-09-29 18:30 +0000
                Re: how to make a macro work as a single line if stmt without braces Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-29 16:39 -0700
                  Re: how to make a macro work as a single line if stmt without braces Kaz Kylheku <643-408-1753@kylheku.com> - 2024-09-30 02:29 +0000
                    Re: how to make a macro work as a single line if stmt without braces Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-09-30 11:26 +0200
                Re: how to make a macro work as a single line if stmt without braces Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-29 18:39 -0700
                Re: how to make a macro work as a single line if stmt without braces Kaz Kylheku <643-408-1753@kylheku.com> - 2024-09-30 02:03 +0000
                Re: how to make a macro work as a single line if stmt without braces David Brown <david.brown@hesbynett.no> - 2024-09-30 13:17 +0200
    Re: how to make a macro work as a single line if stmt without braces Bart <bc@freeuk.com> - 2024-09-21 10:13 +0100
      Re: how to make a macro work as a single line if stmt without braces Mark Summerfield <mark@qtrac.eu> - 2024-09-21 09:53 +0000
    Re: how to make a macro work as a single line if stmt without braces Ike Naar <ike@sdf.org> - 2024-09-21 09:15 +0000
      Re: how to make a macro work as a single line if stmt without braces Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-21 14:44 -0700
    Re: how to make a macro work as a single line if stmt without braces Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-21 06:07 -0700
      Re: how to make a macro work as a single line if stmt without braces Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-21 15:55 -0700
    Re: how to make a macro work as a single line if stmt without braces Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-09-21 12:17 -0700
    Re: how to make a macro work as a single line if stmt without braces Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-09-21 21:18 +0000
      Re: how to make a macro work as a single line if stmt without braces Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-24 06:18 -0700

Page 1 of 4  [1] 2 3 4  Next page →

#388454 — how to make a macro work as a single line if stmt without braces

I have this macro:

#define WARN(...)                                       \
    do {                                                \
        fprintf(stderr, "%s#%d: ", __FILE__, __LINE__); \
        fprintf(stderr, __VA_ARGS__);                   \
    } while (0);

which I use like this:

total++;
if (failed) {
    WARN("failed because...");
} else
    ok++;

I would prefer to be able to write this instead:

total++;
if (failed)
    WARN("failed because...");
else
    ok++;

but doing so results in a compiler error:

error: 'else' without a previous 'if'

[toc] | [next] | [standalone]

#388455

On Sat, 21 Sep 2024 07:35:49 +0000, Mark Summerfield wrote:

> I would prefer to be able to write this instead:
> 
> total++;
> if (failed)
>     WARN("failed because...");
> else
>     ok++;

I wouldn’t, if I were you.

[toc] | [prev] | [next] | [standalone]

#388456

On 21/09/2024 09:35, Mark Summerfield wrote:
> I have this macro:
> 
> #define WARN(...)                                       \
>      do {                                                \
>          fprintf(stderr, "%s#%d: ", __FILE__, __LINE__); \
>          fprintf(stderr, __VA_ARGS__);                   \
>      } while (0);
> 
> which I use like this:
> 
> total++;
> if (failed) {
>      WARN("failed because...");
> } else
>      ok++;
> 
> I would prefer to be able to write this instead:
> 
> total++;
> if (failed)
>      WARN("failed because...");
> else
>      ok++;
> 
> but doing so results in a compiler error:
> 
> error: 'else' without a previous 'if'

You should get in the habit of being consistent with braces, and being 
generous with them.  Your future self with thank you.

if (failed) {
	WARN("failed because...");
} else {
	ok++;
}


The rule here is that you the /only/ time you allow yourself to omit the 
braces is if you have a very simple "if" that has no "else", is small 
enough to fit entirely on a single line, and the statement could not 
possibly be misinterpreted, use a macro, or have any other non-obvious 
behaviour.

Thus :

	if (failed) return -1;		// Early exit

or

	if (!failed) ok++;

Otherwise, put in all the braces.

This also keeps your indentation consistent - open braces are only at 
the end of a line, and the next line starts an indented block.  Close 
braces are only ever the first non-indent character in a line, and you 
un-indent on the close brace.

(It's common to put the opening brace of a function at the start of its 
own line, and braces for struct or array initialisation can be freer.)

do, while and for loops always use braces.



There are a few other variant styles that are also consistent and clear, 
but usually they end up unnecessarily spread out.  (Opinions will vary 
about that.)  But getting good habits here from early one will make your 
code much clearer, greatly reduce the risk of blocking errors, and be a 
significant boon for code maintenance and the use of version control 
systems.

[toc] | [prev] | [next] | [standalone]

#388465

On 09/21/24 1:47 AM, David Brown wrote:
> 
> You should get in the habit of being consistent with braces, and being 
> generous with them.  Your future self with thank you.
> 
> if (failed) {
>      WARN("failed because...");
> } else {
>      ok++;
> }
> 

Nope. There's absolutely no reason to overuse braces.

And don't use "Egyptian" braces. The latter is actually an ill-begotten 
attempt to remedy the damage from the former. Just stop overusing 
braces, and there'll be no need for the remedy. Easy.

This is the proper formatting style with braces

   if (failed)
   {
     ...
   }
   else
   {
     ...
   }

The vertical spacing introduced by the `{` line provides separation 
between condition and the branch, which makes your code much more 
readable. It is also a very good location for a comment, if you decide 
to include one. Your future self with thank you.

> ...  is small
> enough to fit entirely on a single line, and the statement could not 
> possibly be misinterpreted, use a macro, or have any other non-obvious 
> behaviour.
> 
> Thus :
> 
>      if (failed) return -1;        // Early exit
> 
> or
> 
>      if (!failed) ok++;
> 
> Otherwise, put in all the braces.

Nope. Do not ever write single-line `if` statements. This is a major 
impediment to step-by-step debugging.

-- 
Best regards,
Andrey

[toc] | [prev] | [next] | [standalone]

#388467

On 21/09/2024 20:27, Andrey Tarasevich wrote:
> On 09/21/24 1:47 AM, David Brown wrote:
>>
>> You should get in the habit of being consistent with braces, and being 
>> generous with them.  Your future self with thank you.
>>
>> if (failed) {
>>      WARN("failed because...");
>> } else {
>>      ok++;
>> }
>>
> 
> Nope. There's absolutely no reason to overuse braces.
> 
> And don't use "Egyptian" braces. The latter is actually an ill-begotten 
> attempt to remedy the damage from the former. Just stop overusing 
> braces, and there'll be no need for the remedy. Easy.
> 
> This is the proper formatting style with braces
> 
>    if (failed)
>    {
>      ...
>    }
>    else
>    {
>      ...
>    }
> 
> The vertical spacing introduced by the `{` line provides separation 
> between condition and the branch,

Have a look at the middle of that example:

   } else {

Here the braces serve no purpose; you already have 'else' separating the 
two branches to which you can add extra vertical space if you like.

This is not just because of braces, you get the same thing with:

    end else begin

Both are symptoms of the idea that any branch can only have a single 
statement, and if you need more, than you need a compound statement 
using {s1; s2; s3;} (unless you're Tim then you use s1, s2, s3 which may 
or may not work and is probably the worst of all).

Since this is C, then if braces are to be mandatory, then at least allow 
people to write their code a little more compactly if they wish. In a 
language that allows proper statement sequences, you wouldn't commonly 
see this:

     if failed then

         s1

     else

         s2

     ...

But this exactly how you are suggesting C should be written, when 
looking purely at the content: 50% blank lines.

It looks ridiculous and those statements look very lonely!

[toc] | [prev] | [next] | [standalone]

#388469

On 21/09/2024 21:27, Andrey Tarasevich wrote:
 > Nope. There's absolutely no reason to overuse braces.
 >
 > And don't use "Egyptian" braces. The latter is actually an ill-begotten
 > attempt to remedy the damage from the former. Just stop overusing
 > braces, and there'll be no need for the remedy. Easy.
 >
 > This is the proper formatting style with braces
 >
 >    if (failed)
 >    {
 >      ...
 >    }
 >    else
 >    {
 >      ...
 >    }
 >
 > The vertical spacing introduced by the `{` line provides separation
 > between condition and the branch, which makes your code much more
 > readable. It is also a very good location for a comment, if you decide
 > to include one. Your future self with thank you.
I agree with that, but you realize you are kinda fighting 
"establishment" here. What you call "egyptian" braces is the so-called 
"TBS" which has infected the "default style" of approximately all 
programming languages that use braces. People use that almost 
religiously and the only rationale is to save space. Might have made 
sense 40 years ago when screen estate was a lot smaller, but these days, 
it's just madness. It's a lot less readable. The details are also odd: 
they seem to despise having an opening brace alone on a line, but they 
don't mind the closing brace to be.

This is even worse: } else {
starting a line with a closing symbol and ending it with an opening 
symbol, really?

As to overuse, my own style and guideline is this: if both 'then' and 
'else' blocks are single statements, don't use braces.

If any of these blocks have more than one statement, use braces for both 
to make it look consistent. Mixed braces in if/else do look terrible 
IMHO (and the lack of consistency always hinders readablity), like this:

if (something)
     dothis();
else
{
     dothat();
     andalsothat();
}

Just avoid it.

I've seen that code style guideline in various environments, so this 
isn't just my own either.

Now the rationale for always using braces even for single statements at 
least makes some sense. Usually, it's for avoiding the case when a 
developer will add statements to a if or else block, forget to add 
braces to enclose it, and so that becomes a bug (which can't be easily 
trapped by compilers unless it's between a if and else. Some 
compilers/static analyzers, if you at least used proper indenting, will 
spot the indenting and lack of braces and will warn you about a 
potential mistake though.

[toc] | [prev] | [next] | [standalone]

#388473

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
> On 09/21/24 1:47 AM, David Brown wrote:
>> You should get in the habit of being consistent with braces, and
>> being generous with them.  Your future self with thank you.
>> if (failed) {
>>      WARN("failed because...");
>> } else {
>>      ok++;
>> }
>> 
>
> Nope. There's absolutely no reason to overuse braces.

Plenty of C programmers, myself included, disagree with this.

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.

> And don't use "Egyptian" braces. The latter is actually an
> ill-begotten attempt to remedy the damage from the former. Just stop
> overusing braces, and there'll be no need for the remedy. Easy.
>
> This is the proper formatting style with braces
>
>   if (failed)
>   {
>     ...
>   }
>   else
>   {
>     ...
>   }

Again, many, perhaps most, C programmers will disagree with this.

What you call "Egyptian" braces is 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.

[...]

>> Thus :
>>      if (failed) return -1;        // Early exit
>> or
>>      if (!failed) ok++;
>> Otherwise, put in all the braces.
>
> Nope. Do not ever write single-line `if` statements. This is a major
> impediment to step-by-step debugging.

I've rarely run into that problem.  When I have, it's been easy enough
to temporarily modify the code.

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

[toc] | [prev] | [next] | [standalone]

#388483

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.

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

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.

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.

-- 
Best regards,
Andrey

[toc] | [prev] | [next] | [standalone]

#388485

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 */

[toc] | [prev] | [next] | [standalone]

#388491

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!

[toc] | [prev] | [next] | [standalone]

#388530

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

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

[...]

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

Your reasoning is rife with errors of logic and facts not in
evidence.

[toc] | [prev] | [next] | [standalone]

#388490

On 21/09/2024 21:27, Andrey Tarasevich wrote:
> On 09/21/24 1:47 AM, David Brown wrote:
>>
>> You should get in the habit of being consistent with braces, and being 
>> generous with them.  Your future self with thank you.

To be clear here - many people have strong opinions about this topic, 
and there is no good evidence for claiming that one style is "better" 
than other styles.  Different styles can have their pros and cons, and 
people will give different weightings to those pros and cons when 
choosing a style.

So I fully respect your opinion here.  But you are still wrong :-)

>>
>> if (failed) {
>>      WARN("failed because...");
>> } else {
>>      ok++;
>> }
>>
> 
> Nope. There's absolutely no reason to overuse braces.

I am not suggesting overuse of braces.  I am suggesting /good/ use of them.

<https://www.synopsys.com/blogs/software-security/understanding-apple-goto-fail-vulnerability-2.html>

That's perhaps the most famous example of the havoc caused by omitting 
useful braces.

Consistency and clarity is important.  So is maintainability.  Suppose, 
for example, you want to add a line "attempts++;" alongside the "ok++;" 
line.  When the braces are there, the change is exactly that - add the 
new line you want.  Without the original braces, you are now making 
changes to the structural syntax of the code as well when you add in 
original braces - or you are making a mistake in the code.

> 
> And don't use "Egyptian" braces. The latter is actually an ill-begotten 
> attempt to remedy the damage from the former. Just stop overusing 
> braces, and there'll be no need for the remedy. Easy.
> 
> This is the proper formatting style with braces
> 
>    if (failed)
>    {
>      ...
>    }
>    else
>    {
>      ...
>    }
> 
> The vertical spacing introduced by the `{` line provides separation 
> between condition and the branch, which makes your code much more 
> readable. It is also a very good location for a comment, if you decide 
> to include one. Your future self with thank you.

No, it makes code longer and more tedious to read, and wastes 
significant vertical space so that you can see less code at a time.  It 
leads people to think that it is a good idea to skip braces when they 
can.  Put braces in a sensible place and there is no incentive to skip them.

One important point for readability is to keep the conditionals 
relatively short so that the open brace is not far to the right - an 
overly complex expression is usually a bad idea anyway.

> 
>> ...  is small
>> enough to fit entirely on a single line, and the statement could not 
>> possibly be misinterpreted, use a macro, or have any other non-obvious 
>> behaviour.
>>
>> Thus :
>>
>>      if (failed) return -1;        // Early exit
>>
>> or
>>
>>      if (!failed) ok++;
>>
>> Otherwise, put in all the braces.
> 
> Nope. Do not ever write single-line `if` statements. This is a major 
> impediment to step-by-step debugging.
> 

That is indeed true.  Sometimes when you have code that you need to 
single-step or debug carefully, you need to express it a little 
differently or make syntactic changes to help.  (A common one is to mark 
some of the local variables as "volatile".)

I think it is reasonable to have such short one-line conditionals in 
simple cases, but it is certainly not a requirement - filling them out 
with the braces is fine too.

[toc] | [prev] | [next] | [standalone]

#388499

On 2024-09-22, David Brown <david.brown@hesbynett.no> wrote:
> I am not suggesting overuse of braces.  I am suggesting /good/ use of them.
>
><https://www.synopsys.com/blogs/software-security/understanding-apple-goto-fail-vulnerability-2.html>
>
> That's perhaps the most famous example of the havoc caused by omitting 
> useful braces.
>
> Consistency and clarity is important.  So is maintainability.  Suppose, 
> for example, you want to add a line "attempts++;" alongside the "ok++;" 
> line.  When the braces are there, the change is exactly that - add the 
> new line you want.  Without the original braces, you are now making 
> changes to the structural syntax of the code as well when you add in 
> original braces - or you are making a mistake in the code.

My super advanced text editor from the future isn't letting me do that:

  if (failed)
    WARN("failed because...");
  else
    ok++;
  attempts++; // automatic deindent

When I add a line after ok++, it deindents it to be at the same
indentation level as the if, before letting me type any content into it.

OK, I lied about the super advanced from the future. It's just Vim.

Also GCC has been able to diagnose misleading indentation for some
years now.

Between those two, there is nothing to worry about; just concentrate on
whether it looks prettier without the braces or with.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#388500

On 22/09/2024 16:11, Kaz Kylheku wrote:
> On 2024-09-22, David Brown <david.brown@hesbynett.no> wrote:
>> I am not suggesting overuse of braces.  I am suggesting /good/ use of them.
>>
>> <https://www.synopsys.com/blogs/software-security/understanding-apple-goto-fail-vulnerability-2.html>
>>
>> That's perhaps the most famous example of the havoc caused by omitting
>> useful braces.
>>
>> Consistency and clarity is important.  So is maintainability.  Suppose,
>> for example, you want to add a line "attempts++;" alongside the "ok++;"
>> line.  When the braces are there, the change is exactly that - add the
>> new line you want.  Without the original braces, you are now making
>> changes to the structural syntax of the code as well when you add in
>> original braces - or you are making a mistake in the code.
> 
> My super advanced text editor from the future isn't letting me do that:
> 
>    if (failed)
>      WARN("failed because...");
>    else
>      ok++;
>    attempts++; // automatic deindent
> 
> When I add a line after ok++, it deindents it to be at the same
> indentation level as the if, before letting me type any content into it.
> 
> OK, I lied about the super advanced from the future. It's just Vim.
> 
> Also GCC has been able to diagnose misleading indentation for some
> years now.
> 
> Between those two, there is nothing to worry about; just concentrate on
> whether it looks prettier without the braces or with.
> 

So, everyone has to write code exactly to the C standard.

But when it comes to more practical matters, it's OK to depend on the 
arbitrary characteristics and abilities of whichever one of 1001 
different text editors we happen to be using.

Or we have to use a specific compiler with a specific set of options.

 > Also GCC has been able to diagnose misleading indentation for some
 > years now.

How many years was that out of the last 52? How exactly do you turn it 
on? Since -Wall -Wpedantic -Wextra doesn't report it.

It is a failure in the design of the language. You can't really depend 
on ad hoc features of the tools you use to create and compile source code.

At least guidelines can be used such as always using braces, then errors 
can occur less often.

(I've been bitten by this endless times when trying to add debugging 
statements to existing code. If that code consistently used braces, then 
it wouldn't happen.)

[toc] | [prev] | [next] | [standalone]

#388503

On Sun, 22 Sep 2024 16:56:47 +0100
Bart <bc@freeuk.com> wrote:

> On 22/09/2024 16:11, Kaz Kylheku wrote:
> > On 2024-09-22, David Brown <david.brown@hesbynett.no> wrote:  
> >> I am not suggesting overuse of braces.  I am suggesting /good/ use
> >> of them.
> >>
> >> <https://www.synopsys.com/blogs/software-security/understanding-apple-goto-fail-vulnerability-2.html>
> >>
> >> That's perhaps the most famous example of the havoc caused by
> >> omitting useful braces.
> >>
> >> Consistency and clarity is important.  So is maintainability.
> >> Suppose, for example, you want to add a line "attempts++;"
> >> alongside the "ok++;" line.  When the braces are there, the change
> >> is exactly that - add the new line you want.  Without the original
> >> braces, you are now making changes to the structural syntax of the
> >> code as well when you add in original braces - or you are making a
> >> mistake in the code.  
> > 
> > My super advanced text editor from the future isn't letting me do
> > that:
> > 
> >    if (failed)
> >      WARN("failed because...");
> >    else
> >      ok++;
> >    attempts++; // automatic deindent
> > 
> > When I add a line after ok++, it deindents it to be at the same
> > indentation level as the if, before letting me type any content
> > into it.
> > 
> > OK, I lied about the super advanced from the future. It's just Vim.
> > 
> > Also GCC has been able to diagnose misleading indentation for some
> > years now.
> > 
> > Between those two, there is nothing to worry about; just
> > concentrate on whether it looks prettier without the braces or with.
> >   
> 
> So, everyone has to write code exactly to the C standard.
> 
> But when it comes to more practical matters, it's OK to depend on the 
> arbitrary characteristics and abilities of whichever one of 1001 
> different text editors we happen to be using.
> 
> Or we have to use a specific compiler with a specific set of options.
> 
>  > Also GCC has been able to diagnose misleading indentation for some
>  > years now.  
> 
> How many years was that out of the last 52? How exactly do you turn
> it on? Since -Wall -Wpedantic -Wextra doesn't report it.
> 

My gcc warns just fine.

void bar(int);
int foo(int x) {
  if (x)
    bar(x);
    x -= 1;
  return x;
}

gcc -c -Wall foo.c

foo.c: In function 'foo':
foo.c:3:3: warning: this 'if' clause does not guard...
[-Wmisleading-indentation] 3 |   if (x)
      |   ^~
foo.c:5:5: note: ...this statement, but the latter is misleadingly
indented as if it were guarded by the 'if'
    5 |     x -= 1;
      |     ^


> It is a failure in the design of the language. You can't really
> depend on ad hoc features of the tools you use to create and compile
> source code.
> 
> At least guidelines can be used such as always using braces, then
> errors can occur less often.
> 
> (I've been bitten by this endless times when trying to add debugging 
> statements to existing code. If that code consistently used braces,
> then it wouldn't happen.)

I wonder why I was not bitten by that more than, may be, 5 times in
30+ years. Probably, I am doing something wrong.

[toc] | [prev] | [next] | [standalone]

#388504

On 22/09/2024 17:27, Michael S wrote:
> On Sun, 22 Sep 2024 16:56:47 +0100
> Bart <bc@freeuk.com> wrote:
> 
>> On 22/09/2024 16:11, Kaz Kylheku wrote:
>>> On 2024-09-22, David Brown <david.brown@hesbynett.no> wrote:
>>>> I am not suggesting overuse of braces.  I am suggesting /good/ use
>>>> of them.
>>>>
>>>> <https://www.synopsys.com/blogs/software-security/understanding-apple-goto-fail-vulnerability-2.html>
>>>>
>>>> That's perhaps the most famous example of the havoc caused by
>>>> omitting useful braces.
>>>>
>>>> Consistency and clarity is important.  So is maintainability.
>>>> Suppose, for example, you want to add a line "attempts++;"
>>>> alongside the "ok++;" line.  When the braces are there, the change
>>>> is exactly that - add the new line you want.  Without the original
>>>> braces, you are now making changes to the structural syntax of the
>>>> code as well when you add in original braces - or you are making a
>>>> mistake in the code.
>>>
>>> My super advanced text editor from the future isn't letting me do
>>> that:
>>>
>>>     if (failed)
>>>       WARN("failed because...");
>>>     else
>>>       ok++;
>>>     attempts++; // automatic deindent
>>>
>>> When I add a line after ok++, it deindents it to be at the same
>>> indentation level as the if, before letting me type any content
>>> into it.
>>>
>>> OK, I lied about the super advanced from the future. It's just Vim.
>>>
>>> Also GCC has been able to diagnose misleading indentation for some
>>> years now.
>>>
>>> Between those two, there is nothing to worry about; just
>>> concentrate on whether it looks prettier without the braces or with.
>>>    
>>
>> So, everyone has to write code exactly to the C standard.
>>
>> But when it comes to more practical matters, it's OK to depend on the
>> arbitrary characteristics and abilities of whichever one of 1001
>> different text editors we happen to be using.
>>
>> Or we have to use a specific compiler with a specific set of options.
>>
>>   > Also GCC has been able to diagnose misleading indentation for some
>>   > years now.
>>
>> How many years was that out of the last 52? How exactly do you turn
>> it on? Since -Wall -Wpedantic -Wextra doesn't report it.
>>
> 
> My gcc warns just fine.
> 
> void bar(int);
> int foo(int x) {
>    if (x)
>      bar(x);
>      x -= 1;
>    return x;
> }
> 
> gcc -c -Wall foo.c
> 
> foo.c: In function 'foo':
> foo.c:3:3: warning: this 'if' clause does not guard...
> [-Wmisleading-indentation] 3 |   if (x)
>        |   ^~
> foo.c:5:5: note: ...this statement, but the latter is misleadingly
> indented as if it were guarded by the 'if'
>      5 |     x -= 1;
>        |     ^
> 

That doesn't pick up a program that in my editor looks like this:

------------------------
int main(void){
total++;
if (failed)
     WARN("failed because...");
else
     ok++;
     failed=0;
}
------------------------

However, the first two indents use four spaces, but the third uses a 
hard tab that my editor shows as four spaces, but if I print it out to 
the console, it shows this:

------------------------
int main(void){
total++;
if (failed)
     WARN("failed because...");
else
     ok++;
         failed=0;
}
------------------------

That odd indentation is not picked up either. But it will say something 
if all indents used spaces or used hard tabs.

If the language has explicit block delimiters (either mandatory braces, 
or endings like 'end'), then the problem simply wouldn't arise. That 
'failed=0' line would either be before the delimiter or after it. The 
original example would look something like this:


------------------------
if (failed) {
     WARN("failed because...");
} else {
     ok++;
}
     failed=0;
------------------------
That line is still mis-indented, but is now less likely to be taken to 
be part of that 'else' block.






>> It is a failure in the design of the language. You can't really
>> depend on ad hoc features of the tools you use to create and compile
>> source code.
>>
>> At least guidelines can be used such as always using braces, then
>> errors can occur less often.
>>
>> (I've been bitten by this endless times when trying to add debugging
>> statements to existing code. If that code consistently used braces,
>> then it wouldn't happen.)
> 
> I wonder why I was not bitten by that more than, may be, 5 times in
> 30+ years. Probably, I am doing something wrong.

How you tried to debug other people's code via adding printf statements 
at strategic points?

[toc] | [prev] | [next] | [standalone]

#388515

Michael S <already5chosen@yahoo.com> writes:

> On Sun, 22 Sep 2024 16:56:47 +0100
> Bart <bc@freeuk.com> wrote:
>
>> On 22/09/2024 16:11, Kaz Kylheku wrote:
>>
>>> On 2024-09-22, David Brown <david.brown@hesbynett.no> wrote:
>>>
>>>> I am not suggesting overuse of braces.  I am suggesting /good/ use
>>>> of them.
>>>>
>>>> <https://www.synopsys.com/blogs/software-security/
>>>>     understanding-apple-goto-fail-vulnerability-2.html>
>>>>
>>>> That's perhaps the most famous example of the havoc caused by
>>>> omitting useful braces.
>>>>
>>>> Consistency and clarity is important.  So is maintainability.
>>>> Suppose, for example, you want to add a line "attempts++;"
>>>> alongside the "ok++;" line.  When the braces are there, the change
>>>> is exactly that - add the new line you want.  Without the original
>>>> braces, you are now making changes to the structural syntax of the
>>>> code as well when you add in original braces - or you are making a
>>>> mistake in the code.
>>>
>>> My super advanced text editor from the future isn't letting me do
>>> that:
>>>
>>>    if (failed)
>>>      WARN("failed because...");
>>>    else
>>>      ok++;
>>>    attempts++; // automatic deindent
>>>
>>> When I add a line after ok++, it deindents it to be at the same
>>> indentation level as the if, before letting me type any content
>>> into it.
>>>
>>> OK, I lied about the super advanced from the future.  It's just
>>> Vim.
>>>
>>> Also GCC has been able to diagnose misleading indentation for some
>>> years now.
>>>
>>> Between those two, there is nothing to worry about;  just
>>> concentrate on whether it looks prettier without the braces or
>>> with.
>>
>> So, everyone has to write code exactly to the C standard.
>>
>> But when it comes to more practical matters, it's OK to depend on
>> the arbitrary characteristics and abilities of whichever one of
>> 1001 different text editors we happen to be using.
>>
>> Or we have to use a specific compiler with a specific set of
>> options.
>>
>>> Also GCC has been able to diagnose misleading indentation for some
>>> years now.
>>
>> How many years was that out of the last 52?  How exactly do you
>> turn it on?  Since -Wall -Wpedantic -Wextra doesn't report it.
>
> My gcc warns just fine.
>
> void bar(int);
> int foo(int x) {
>   if (x)
>     bar(x);
>     x -= 1;
>   return x;
> }
>
> gcc -c -Wall foo.c
>
> foo.c:  In function 'foo':
> foo.c:3:3: warning: this 'if' clause does not guard...
> [-Wmisleading-indentation] 3 |   if (x)
>       |   ^~
> foo.c:5:5: note: ...this statement, but the latter is misleadingly
> indented as if it were guarded by the 'if'
>     5 |     x -= 1;
>       |     ^
>
>
>> It is a failure in the design of the language.  You can't really
>> depend on ad hoc features of the tools you use to create and
>> compile source code.
>>
>> At least guidelines can be used such as always using braces, then
>> errors can occur less often.
>>
>> (I've been bitten by this endless times when trying to add
>> debugging statements to existing code.  If that code consistently
>> used braces, then it wouldn't happen.)
>
> I wonder why I was not bitten by that more than, may be, 5 times
> in 30+ years.  Probably, I am doing something wrong.

My long-standing habit is to write this

   if(x)  bar(x);

or this

   if(x){
      bar(x);
   }

but never this

   if(x)
      bar(x);

The reason for this habit is that many years ago I got bitten by
trying to add a line in the last case.  The habit subsequently
adopted has proven very effective at eliminating such errors.

The idea of changing the language to always require braces is
unnecessary and wasteful (besides being a non-starter for purely
practical reasons).

[toc] | [prev] | [next] | [standalone]

#388516

On 09/24/24 7:36 AM, Tim Rentsch wrote:
> 
> My long-standing habit is to write this
> 
>     if(x)  bar(x);
> 
> or this
> 
>     if(x){
>        bar(x);
>     }
> 
> but never this
> 
>     if(x)
>        bar(x);
> 
> The reason for this habit is that many years ago I got bitten by
> trying to add a line in the last case.  The habit subsequently
> adopted has proven very effective at eliminating such errors.
> 

It is just weird.

This is no different from insisting in using "Yoda conditions", claiming 
that "many years ago I was bitten by an accidental = in place of ==". In 
reality we all know that regardless of how many scary stories someone 
might tell about dangers of accidental assignment in place of 
comparison, it just does not happen. There's no such issue. People just 
don't make this mistake.

The same applies to

   if(x)
     bar(x);

This is the right thing to do. It is the most readable and elegant way 
to write a simple `if`. And the dreaded "one day you will add a line and 
suffer" just doesn't happen. There's no such issue. People just don't 
make this mistake.

-- 
Best regards,
Andrey

[toc] | [prev] | [next] | [standalone]

#388517

On 24/09/2024 16:52, Andrey Tarasevich wrote:
> On 09/24/24 7:36 AM, Tim Rentsch wrote:
>>
>> My long-standing habit is to write this
>>
>>     if(x)  bar(x);
>>
>> or this
>>
>>     if(x){
>>        bar(x);
>>     }
>>
>> but never this
>>
>>     if(x)
>>        bar(x);
>>
>> The reason for this habit is that many years ago I got bitten by
>> trying to add a line in the last case.  The habit subsequently
>> adopted has proven very effective at eliminating such errors.
>>
> 
> It is just weird.
> 
> This is no different from insisting in using "Yoda conditions", claiming 
> that "many years ago I was bitten by an accidental = in place of ==". In 
> reality we all know that regardless of how many scary stories someone 
> might tell about dangers of accidental assignment in place of 
> comparison, it just does not happen. There's no such issue. People just 
> don't make this mistake.

They do.

You might not do so, but other people do.  Not often, but still too often.

(I don't think Yoda conditions are the answer here - automatic checking 
from tools is simple enough.)

> 
> The same applies to
> 
>    if(x)
>      bar(x);
> 
> This is the right thing to do. It is the most readable and elegant way 
> to write a simple `if`. And the dreaded "one day you will add a line and 
> suffer" just doesn't happen. There's no such issue. People just don't 
> make this mistake.
> 

Again, people do.

I gave you a link earlier to a hugely costly example of this mistake, 
made by very experienced C programmers.

But I am confident that Tim, and others (like me) who use a similar 
style, are almost entirely immune to this particular mistake.

Now, if there were a good way to automatically detect mixups between & 
and &&, | and ||, then we'd be rid of a number of these kinds of errors 
in C coding.

[toc] | [prev] | [next] | [standalone]

#388518

On 24/09/2024 15:52, Andrey Tarasevich wrote:
> On 09/24/24 7:36 AM, Tim Rentsch wrote:
>>
>> My long-standing habit is to write this
>>
>>     if(x)  bar(x);
>>
>> or this
>>
>>     if(x){
>>        bar(x);
>>     }
>>
>> but never this
>>
>>     if(x)
>>        bar(x);
>>
>> The reason for this habit is that many years ago I got bitten by
>> trying to add a line in the last case.  The habit subsequently
>> adopted has proven very effective at eliminating such errors.
>>
> 
> It is just weird.
> 
> This is no different from insisting in using "Yoda conditions", claiming 
> that "many years ago I was bitten by an accidental = in place of ==". In 
> reality we all know that regardless of how many scary stories someone 
> might tell about dangers of accidental assignment in place of 
> comparison, it just does not happen. There's no such issue. People just 
> don't make this mistake.
> 
> The same applies to
> 
>    if(x)
>      bar(x);
> 
> This is the right thing to do. It is the most readable and elegant way 
> to write a simple `if`.

Well, it is the ONLY way C provides to write the branches of an 
if-statement. Each only takes a single statement.

For more than one statement in a branch, they have to be enclosed in a 
compound statement with braces.

> And the dreaded "one day you will add a line and 
> suffer" just doesn't happen. There's no such issue.

No, this must happen ALL THE TIME. That is, you write one statement, 
then decide you need more than one. Or you start with 3 statements and 
get rid of two of them.

So, what happens: is there are some of sort dance where you add {,} 
braces when N increases beyond 1, and remove them when N reaches 1 again?

What happens when N changes from 1 to 0 (eg. a statement is temporarily 
commented out? Without braces, this will causes problems (unless somehow 
you have its closing";" on its own line), because then the following 
statement is taken to be the branch, with an additional problem if 
'else' actually follows.

I haven't even got to the bit where you might make a mistake that is not 
picked up by a compiler.

It's a just one big palaver that can solved easily by always using a 
compound statement which has opening and closing braces. Within such a 
statement, N can vary between 0, 1 and any other number, any of 
combination can be commented out, without needing to take any special 
action.

It can also happen that when starting to write a branch, you don't know 
what N is going to be, or maybe the statements will be filled in later. 
Here it is useful to have {} as a placeholder for those statements.



> People just don't 
> make this mistake.

And there is that too. Maybe YOU don't make it, in the same way that you 
probably know all the binary operator precedences by heart and never get 
them wrong. Well, not everyone is perfect.

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web