Re: else ladders practice

On 01.12.2024 23:23, Waldek Hebisch wrote:

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 01.12.2024 13:41, Waldek Hebisch wrote:

Stefan Ram <ram@zedat.fu-berlin.de> wrote:

>
  My bad if the following instruction structure's already been hashed
  out in this thread, but I haven't been following the whole convo!
>
  In my C 101 classes, after we've covered "if" and "else",
  I always throw this program up on the screen and hit the newbies
  with this curveball: "What's this bad boy going to spit out?".
>
  Well, it's a blue moon when someone nails it. Most of them fall
  for my little gotcha hook, line, and sinker.
>
#include <stdio.h>
>
const char * english( int const n )
{ const char * result;
  if( n == 0 )result = "zero";
  if( n == 1 )result = "one";
  if( n == 2 )result = "two";
  if( n == 3 )result = "three";
  else        result = "four";
  return result; }
>
void print_english( int const n )
{ printf( "%s\n", english( n )); }
>
int main( void )
{ print_english( 0 );
  print_english( 1 );
  print_english( 2 );
  print_english( 3 );
  print_english( 4 ); }
>

>
That breaks two rules:
- instructions conditioned by 'if' should have braces,

>
I suppose you don't mean
>
  if (n == value) { result = string; }
  else            { result = other; }
>
which I'd think doesn't change anything. - So what is it?
>
Actually, you should just add explicit 'else' to fix the problem.
(Here there's no need to fiddle with spurious braces, I'd say.)

 
Lack of braces is a smokescreen hiding the second problem.
Or to put if differently, due to lack of braces the code
immediately smells bad.

I know what you mean. Though since in the given example it's not
the braces that correct the code, and I also think that adding the
braces doesn't remove the "bad smell" (here). - YMMV, of course. -
For me the smell stems from the use of sequences of 'if' (instead
of 'switch'), and the lacking 'else' keywords. - Note that the OP's
original code *had* braces; it nevertheless had a "bad smell", IMO.

Spurious braces may even make the code less readable; so it depends.
And thus a "brace rule" can (IME) only be a "rule of thumb" and any
"codified rule" (see below) should reflect that.

 

- when we have the result we should return it immediately.

>
This would suffice to fix it, wouldn't it?

 
Yes (but see above).
 

Once those are fixed code works as expected...

>
I find this answer - not wrong, but - problematic for two reasons.
There's no accepted "general rules" that could get "broken"; it's
just rules that serve in given languages and application contexts.
And they may conflict with other "rules" that have been set up to
streamline code, make it safer, or whatever.

 
No general rules, yes.  But every sane programmer has _some_ rules.
My point was that if you adopt resonable rules, then whole classes
of potential problems go away.

I associated the term "rule" with formal coding standards, so that
I wouldn't call personal coding habits "rules" but rather "rules of
thumb" (formal coding standards have both). But personal projects
(and programmers' habits) are anyway not my major concern, while
coding standards actually are. When you formulate coding standards
(and I've done that for a couple languages) you often have to walk
on the edge of what's possible and what's sensible.

Janis