Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: else ladders practice
Date: Sat, 2 Nov 2024 11:44:02 +0100
Organization: A noiseless patient Spider
Lines: 81
Message-ID: <vg4vpi$3oi5g$1@dont-email.me>
References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org>
 <20241031161545.aed6541ce6c728923a46e9df@g{oogle}mail.com>
 <vg0hhn$2psrf$1@dont-email.me> <vg254o$3652k$1@dont-email.me>
 <vg42jk$3gipd$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 02 Nov 2024 11:44:06 +0100 (CET)
Injection-Info: dont-email.me; posting-host="45c6799a6dc3dae663970e7edcbf3c31";
	logging-data="3950768"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19fPDxZ7cpSG6pPUGkk+WYOKVb6k/0L0JI="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:rEYRf+LlIifRH423GxwsWrpds+U=
In-Reply-To: <vg42jk$3gipd$1@dont-email.me>
Content-Language: en-GB
Bytes: 4764

On 02/11/2024 03:25, James Kuyper wrote:
> On 11/1/24 04:56, David Brown wrote:
>> On 31/10/2024 19:16, James Kuyper wrote:
>>> On 10/31/24 09:15, Anton Shepelev wrote:
>>>> fir:
>>>>
>>>>> somethins i got such pies of code like
>>>>>
>>>>> if(n==1) {/*something/}
>>>>> if(n==2) {/*something/}
>>>>> if(n==3) {/*something/}
>>>>> if(n==4) {/*something/}
>>>>> if(n==5) {/*something/}
>>>>>
>>>>> technically i would need to add elses
>>>>
>>>> Why?
>>>
>>> He has indicated that the value of n is not changed inside any of the
>>> if-clauses. A sufficiently sophisticated compiler could notice that
>>> fact, and also that each of the conditions is on the same variable, and
>>> as a result it could generate the same kind of code as if it had been
>>> written with 'else', so it won't generate unnecessary condition tests.
>>> It might, in fact, generate the same kind of code which would have been
>>> generated if it had been coded properly, as a switch statement, so it
>>> might use a jump table, if appropriate.
>>> But it's better to write it as a switch statement in the first place, so
>>> you don't have to rely upon the compiler being sufficiently
>>> sophisticated to get the best results.
>>
>> I disagree entirely.
>>
>> It is best to write the code in the way that makes most sense -
>> whatever gives the best clarity and makes the programmer's intentions
>> obvious to readers, and with the least risk of errors. Consider the
>> maintainability of the code - is it likely to be changed in the
>> future, or adapted and re-used in other contexts? If so, that should
>> be a big influence on how you structure the source code. Can a
>> different structure make it less likely for errors to occur unnoticed?
>> For example, if the controlling value can be an enumeration then with
>> a switch, a good compiler can check if there are accidentally
>> unhandled cases (and even a poor compiler can check for duplicates).
> 
> I don't see those criteria as conflicting with my advice. A switch seems
> to me to unambiguously the clearest way of writing this logic, for
> precisely the same reason it also makes it easier for unsophisticated
> compilers to optimize it - what needs to be done is clearer both to the
> compiler and to the human reader.
> 

It's not the advice itself that I disagree with - it is the /reason/ for 
the advice.

Coding always has some trade-offs, and how you weight different factors 
such as portability and code efficiency depends on the task at hand. 
Unless you know there are other more important factors, the appropriate 
balance for most code is to put the emphasis on code clarity over code 
efficiency, as that typically improves your chances of getting it 
correct.  (And correct results always trump fast results.)

As a bonus, writing code clearly - from a human programmer perspective - 
often results in code that a compiler can optimise well.  But that's not 
the motivation.


Your advice was to write a switch because compilers can generate more 
efficient code even if the compiler is not particularly sophisticated. 
That might be the right advice, but it is the wrong reasoning.


The OP should write the code that is /clearest/ for the task in hand. 
It is certainly likely that a switch is often clearest for this kind of 
structure - but perhaps something else fits better for the OP's purpose.

Or if code efficiency really is an issue for the OP's task, then he 
should write it in half a dozen different ways, test them, and compare 
the speed in reality.