Re: short-circuit control forms

["Mark Lundquist" <up.yerz@nospam.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."
>

That sounds like a good standard, modulo the issue of how to handle
side-effects in functions (let's not go there...)

> 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".

I would say that's not good practice (see below)...

>
> 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?

OK...

First of all, rewriting all conditionals this way is not necessarily an
optimization.  It all depends on what the expressions are, and whether there
is an "expected case".  The notion that short circuit forms are always
faster is an oversimplification.

Then, supposing you did get a net speedup if everyone did this... would it
be worth it?  Someone might say, "well, it can't hurt," (but see above),
"and as long as I'm in the neighborhood here, I might as well do it".  But
those changes don't quite come for free:

- Readers of code reasonably assume that things are the way they are for a
reason.  I don't think "we thought short circuit forms were faster" counts
as a good reason, and so I would expect that most readers would get the
impression that there is some other reason why it must be that way.  If it's
not really true, then the intent is obscured and the understanding process
is slowed down.

- Blindly replacing like this *is* error-prone, because you have to make
sure you're not losing side-effects that change the behavior of the program.
If there is cost to verifying this, then that's part of the cost of making
the change.

- If the programmer is checking in the change as part of another change, it
leaves the impression that it was necessary for whatever development
activity the new version is required for.  Again, confusing.

- Alternatively, they might try to "keep it clean", and create a new version
just for changing an "and" to an "and then" or whatever (I'll bet they don't
do that, but...:-)  But now we are creating a new version for a performance
difference that might only be marginally better.  The new version is subject
to the change propagation process.  And every additional version makes it a
little more difficult to follow the change log.  So there is a cost.

- If you added up all the time that programmers spend doing dubious
hand-optimizations, there's some opportunity cost there... they could
instead be doing hand-optimization the right way, which is to measure and
find out where the bottlenecks are, then figure out how to make those
bottlenecks *significantly* faster.

- Lastly, you have a standard in place, and programmers who are blowing it
off for their own reasons.  So the organization should do one of three
things: (a) say "Who needs a standard, anyway?" and chuck it; (b) say, "Our
standard is broken, let's fix it" (if that were the case :-); or, (c) tell
the programmers they need a better reason to blow off the standard, and to
quit going off half-cocked.  A good way might be to require some formality
for exceptions to your guideline.  That ought to cure them of this
tendency...

Have fun,
Mark Lundquist