Darin McBride wrote in a message to Thomas Seeling:

 TS>  JdBP> if (!terminating) {
 TS>  JdBP> } else {

 TS> I don't think it is good style to handle both cases of 
 TS> a boolean decision and begin with the negated part. 
 TS> Probably the compiler can optimize it, but I wouldn't 
 TS> trust this :)

 TS> if (terminating) {}
 TS> else {}

 TS> is clearer, although your style fits the causality better :-)

 DM> Generally people try to put the error handling (and other
 DM> less-frequently run) code later.  "Terminating" is likely an
 DM> "error" (or at least not the normal path of execution), and
 DM> probably should be handled later.  OTOH, I prefer my
 DM> variables to be positive as well - rather than
 DM> "terminating," have "still_going" or
"alive" or even (if all
 DM> is lost), "not_terminating".  :-)  You win both ways - you
 DM> don't continually negate the variable, and you still get to
 DM> put the most-executed code first where we can read it
 DM> easier.  :-)

From a machine level point of view, you want branches to be not taken more
frequently than taken.  This is because taking a branch always flushes the
prefetch instruction queue in the Intel processors, and this can be a
severe speed penalty if the branch is inside a loop or some similarly
critical code.  A high level language compiler has no way to know whether
the programmer expects the branch to be taken or not, so optimization
cannot be depended upon to handle this.  The heuristic used by most
compilers in optimizing a branch is simply to decide which outcome
generates more code and assume that forward branches to larger code and
backward branches to shorter code will be taken more frequently, the idea
being that forward branches are usually exception tests and backward
branches are usually loops.

Unless you are in a truly critical area of the code, it is my opinion that
the paramount issue is source readability.  If you really need to worry
about this level of detail, you need a profiler and probably should be
working in assembly language in the first place.
 
-- Mike


---