Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: Which code style do you prefer the most?
Date: Sun, 2 Mar 2025 13:21:00 +0100
Organization: A noiseless patient Spider
Lines: 89
Message-ID: <vq1ifc$ou6s$1@dont-email.me>
References: <vpkmq0$21php$1@dont-email.me> <vpl2k4$24fmt$1@dont-email.me>
 <20250225104754.267@kylheku.com> <878qps2abs.fsf@onesoftnet.eu.org>
 <20250226095615.829@kylheku.com> <7wJvP.420809$yI2a.217056@fx42.iad>
 <861pvfyha4.fsf@linuxsc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 02 Mar 2025 13:21:01 +0100 (CET)
Injection-Info: dont-email.me; posting-host="e34113db79e89efb1cf30712b20c3094";
	logging-data="817372"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19e6b+2lpPVEgwfoBEzaG7za/F4Oaw70lI="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:xeIG7TTeyF2xQlrzwS3QT2Ei5WQ=
In-Reply-To: <861pvfyha4.fsf@linuxsc.com>
Content-Language: en-GB
Bytes: 4078

On 02/03/2025 09:21, Tim Rentsch wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
> 
>> Kaz Kylheku <643-408-1753@kylheku.com> writes:
>>
>>> On 2025-02-26, Ar Rakin <rakinar2@onesoftnet.eu.org> wrote:
>>>
>>>> Sorry, I should have showed this difference in my original post.
>>>> I like the GNU style except the weird indentation before the
>>>> braces of control statements.  Not sure why they choose to indent
>>>> that way.
>>>>
>>>> The GNU style without indent before braces looks nice to me.
>>>
>>> Without the weird brace indent, it has nothing to do with GNU any
>>> more;  it's just two-space indentation, where opening braces are on
>>> their own line instead of being "cuddled" into the previous line,
>>> which is very common:
>>>
>>>   if (flag)
>>>   {
>>>     switch (state)
>>>     {
>>>       case 42:
>>>       {
>>>         state = 73;
>>>         break;
>>>       }
>>>     }
>>>   }
>>>   else
>>>   {
>>>     statement;
>>>   }
>>
>> There's so much vertical space wasted in that, however.
>>
>>    if (flag && (state == 42)) state = 73;
>>    else                       statement;

The semantics here are different, yes - if "flag" is true and "state" is 
not 42, the original version does not run "statement;" while the 
re-write does run it.

> 
> The suggested rewrite has different semantics.  Instead
> 
>      if(flag)  state = state == 42 ? 73 : state;
>      else      statement;
> 

The semantics here are different from the original - introducing a 
spurious write to "state" could be observable behaviour or subject to an 
additional data race if "state" is "volatile", atomic, or interacts with 
other threads.

> or
> 
>      if(flag)  state != 42 || (state = 73);
>      else      statement;
> 
> has the same behavior as the original.  (Disclaimer: not
> compiled.)

The semantics here are also possibly different from the original if 
"state" is volatile or atomic.  The details of volatile accesses are 
implementation-defined - the evaluation "(state = 73)" with a volatile 
"state" may re-read "state" after the assignment, or may not.

Re-writes of code can have subtle complications when you don't know the 
full context.  This is one reason people working on serious and 
safety-critical software don't faff around with expressions like those 
ones, and prefer clear and unambiguous code that can't be misinterpreted 
by other programmers, or compilers, regardless of the circumstances.  If 
you want to eliminate the switch, consider this :

     if (flag) {
         if (state == 42) {
             state = 73;
         }
     } else {
         statement;
     }


Yes, it is more verbose - but it is absolutely clear, and there is no 
doubt what is going on even if there are volatiles, atomics, or threads 
involved.