Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: how to make a macro work as a single line if stmt without braces
Date: Sun, 22 Sep 2024 14:15:28 +0200
Organization: A noiseless patient Spider
Lines: 86
Message-ID: <vcp1p1$26p7b$2@dont-email.me>
References: <PaWdnZ3R-9zI6nP7nZ2dnZfqn_GdnZ2d@brightview.co.uk>
 <vcm16e$1hm2u$1@dont-email.me> <vcn6m8$1n1vu$1@dont-email.me>
 <87frpsr7tf.fsf@nosuchdomain.example.com> <vco1ig$20c3r$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 22 Sep 2024 14:15:29 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="92d2f9b37acfcaeb5a5d0a5a62bab213";
	logging-data="2319595"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18jk1dOyYtdS6ahRZuk6SIJoaDgbDZfmiQ="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:lOY9dswbDheMtyT+KLApaRYYGWY=
Content-Language: en-GB
In-Reply-To: <vco1ig$20c3r$1@dont-email.me>
Bytes: 4661

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!