Re: short-circuit control forms

["Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>]

The first thing to ask is this: Are you *really* sure that whatever
inefficiency is introduced is going to matter? Many programmers have an
"efficiency fetish" (especially when they come out of a C programming mode)
that makes no sense in the target environment. I can't imagine a few extra
instructions in some condition checks are going to kill most programs. For
most apps it probably isn't even perceptable.

If that is the case, then the argument goes like this: "It isn't going to
hurt anything if you follow the written-down guidelines and the Ada95
Quality & Style guide. Future releases of the compiler may be able to do the
optimization for you (and do it better) and in the mean time, you will be
producing code that is remarkably like what our style guidelines dictate &
thus will make life easier for 'the other guy' when he has to read it. It
may also prevent hard to find errors in the code by forcing evaluation of
all conditions anyway. (Imagine a condition that *mostly* gets bypassed
because of an 'and then" and it isn't until some later point in the project
that the condition comes up - intermittently - causing some kind of runtime
error.)"

When you've got a situation where those few extra instructions are making a
difference in performance or threatening success of the project, then you go
ahead and pull every efficiency trick you can to get the code you need from
the compiler. That should be the *exception* to the style guide that is done
only where necessary.

Now if you want to debate the relative merits of what the style guide says -
that's another discussion. Someone might reasonably argue that this
guideline has no merit and should be abandoned. However that is a decision
that the development group as a whole should arrive at and not something
that should be violated by a lone wolf or two who just don't feel like
playing nice. The issue there is that if the style guide can just be
arbitrarily pitched by whoever wants to do so whenever they feel like it,
then what is the point of having one?

Managing programmers is like herding cats.

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"James A. Krzyzanowski" <James_A_Krzyzanowski@raytheon.com> wrote in message
news:3B30F836.D700DAA3@raytheon.com...
> Looking for expert opinions...
>
> We have a company standard which states:
> "standard => Use short-circuit control forms to specify the order of
>              conditions when the failure of one condition means that
>              the other condition will raise an exception.
>  guideline => Avoid short-circuit control forms otherwise."
>
> Our software engineers believe that using short-circuit control forms
> will make our software more efficient (speed-wise).  So, they have been
> replacing every "and" with "and then" and every "or" with "or else".
>
> We use Rational Apex and a Rational Representative sent correspondence
> basically saying that their compiler will NOT optimize plain "and" and
> "or" to behave as though the best "and then" and "or else" order has
> been specified.
>
> The reason for our standard on this topic is because we expected the
> compiler to be smarter than the software engineer when it comes to
> specifying an order of conditions.  This is also consistent with
> Ada 95 Quality and Style: Guidelines for Professional Programmers.
>
> If using "and then" and "or else" will make our software quicker, and
> then the compiler doesn't optimize any better anyway, does anybody have
> a good reason why we should NOT use short-circuit control forms?
>
> --
> --------------------------------------------------------------------------
-
>          James A. Krzyzanowski - Staff Software Engineer - AFATDS
%c%
>      Raytheon Systems Company * Fort Wayne, IN 46808 * (219) 429-6446
cus
>                  mailto:James_A_Krzyzanowski@raytheon.com
%s%
> --------------------------------------------------------------------------
-