Re: else ladders practice

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.