Re: Coding for Obscurity

[Mark Wilden <Mark@mWilden.com>]

Robert S. White wrote:
> 
> In article <3479F8FB.2D7F@mWilden.com>, Mark@mWilden.com says...
> 
> >But ?: is not an idiom; it's a part of the language definition. I'll
> >give you the benefit of the doubt and assume that when you think it
> >through, you understand it.
> 
>   I _understood_ it in 1983.

I was talking about understanding a line of code and you're talking
about understanding a syntax element, but never mind.

> But right now in thinking about
> it, I'll say that it would have been better from a code maintenance
> point of view, that K&R had never thought of it as a convenient
> typing shortcut.  IMHO YMMV

I don't look at it like that at all. I certainly would never use it
instead of an if-statement just to save some typing (in fact, I don't
use it very often at all). C/C++ is naturally a terse language, however,
and one of the advantages of terseness, used appropriately, is the
ability to let the reader "chunk" in order to understand the code
faster. Terseness also can have maintenance benefits, in reducing
duplication.

For example, here's a case where I used the conditional operator
recently:

  EnableMenuItem(hGameMenu, ID_NEWLIFE,
    (CanBeReborn() ? MF_ENABLED : MF_GRAYED) | MF_BYCOMMAND);

I think this is easier to read and maintain than either

  // redundant--bad for maintenance
  if (CanBeReborn())
     EnableMenuItem(hGameMenu, ID_NEWLIFE, MF_ENABLED | MF_BYCOMMAND);
  else
     EnableMenuItem(hGameMenu, ID_NEWLIFE, MF_GRAYED | MF_BYCOMMAND);

or

 // wordy--takes longer to read and understand
 // reader may wonder if flag is used further down
 unsigned flag;
 if (CanBeReborn())
    flag = MF_ENABLED;
 else
    flag = MF_GRAYED;
 EnableMenuItem(hGameMenu, ID_NEWLIFE, flag | MF_BYCOMMAND);