From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,db5c6b2ef47d4b9e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-06-20 17:13:59 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!hammer.uoregon.edu!enews.sgi.com!newshub2.rdc1.sfba.home.com!news.home.com!news1.sttls1.wa.home.com.POSTED!not-for-mail From: "Mark Lundquist" Newsgroups: comp.lang.ada References: <3B30F836.D700DAA3@raytheon.com> Subject: Re: short-circuit control forms X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Message-ID: Date: Thu, 21 Jun 2001 00:13:59 GMT NNTP-Posting-Host: 24.20.66.39 X-Complaints-To: abuse@home.net X-Trace: news1.sttls1.wa.home.com 993082439 24.20.66.39 (Wed, 20 Jun 2001 17:13:59 PDT) NNTP-Posting-Date: Wed, 20 Jun 2001 17:13:59 PDT Organization: Excite@Home - The Leader in Broadband http://home.com/faster Xref: archiver1.google.com comp.lang.ada:8948 Date: 2001-06-21T00:13:59+00:00 List-Id: "James A. Krzyzanowski" 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