Re: short-circuit control forms (& 'long names are doom')

[Wes Groleau <wwgrol@ftw.rsc.raytheon.com>]

> There was an interesting thread on this subject back in 95 (search for short
> circuit in the Google archives of comp.lang.ada).

Didn't work.  Seeral search methods only returned parts
of this (current) thread.

> I found Tucker Taft's comment particularly interesting:
> 
> ": If both operands are
>  : always evaluated, does that mean that whenever it is unnecessary to
>  : evaluate the second operand, one should use the short-circuit operators
>  : for efficiency?

I hope he's listening, because without seeing the whole post,
I strongly suspect that his answer was "no"

>  To avoid depending on the quality of your compiler's optimizer,
>  I personally recommend using short-circuit operations by default,
>  and only use "and" or "or" when it is *required* that both
>  operands be evaluated.

I do not recommend "depending on" the optimizer, but
I recommend even more strongly NOT disabling the optimizer.

>  Hence, if your compiler is clever, it doesn't matter what you
>  do since it will un-do it if appropriate, and if your compiler is

If  _allowed_  and appropriate.

>  not clever, then using short-circuit by default probably produces
>  somewhat better code quality on average.

For reasons already stated in this thread, I doubt it.  That's if
you define "code quality" as "efficient."  If you define it as clear,
readable, and less error-prone, then for reasons already stated
in this thread, I doubt it.

What surprises me the most about our "profession" in general
is the fact that the folks "in the trenches" habitually ignore
the good advice of the "experts" that we claim to respect.

Since nearly THIRTY YEARS AGO (and probably longer), folks have
known and written of the foolishness of misguided "optimization"
efforts (emphasis mine):

   Kernighan & Plauger, 1974.  Elements of Programming Style:

     Make it right _before_ you make it faster.

     _Keep_it_right_ when you make it faster.

     Make it clear _before_ you make it faster.

     Don't sacrifice _clarity_ for small gains in "efficiency."

     Let your _compiler_ do the simple optimizations.

     Keep it _simple_ to make it faster.
        [I have fixed at least as many bugs by
         _removing_ code as I have by adding code. -WWG]

     Don't diddle code to make it faster � find a better algorithm.

     Instrument your programs.  _Measure_ before making "efficiency" changes.

   Ledgard, Nagin, Hueras, 1979.
   Pascal with Style: Programming Proverbs:

     Shortening the code, running the program faster,
     or using fewer variables are all popular pastimes. .....
     Not mentioning ... the extra testing time needed
     to check the new and often subtle boundary conditions,
     are you _sure_ that fewer machine instructions or
     faster machine execution is likely?

   Some others which I have not been able to verify the sources of:

     Rules of Optimization:
     Rule 1: Don't do it.
     Rule 2 (for experts only): Don't do it yet.
        - M.A. Jackson

     "More computing sins are committed in the name of efficiency
     (without necessarily achieving it) than for any other single
     reason - including blind stupidity."
        - W.A. Wulf

     "We should forget about small efficiencies, say about 97% of
     the time: premature optimization is the root of all evil."
        - Donald Knuth

-- 
Wes Groleau
http://freepages.rootsweb.com/~wgroleau