>When writing if-statements that have an AND, always put the quickest executing condition first.

This would matter a lot only if those if statements were in a bottleneck of the program, e.g. in a loop or nested loop that ran a high number of times. (Unless you are trying to squeeze out the last few cycles of performance). Or am I getting you wrong?

>always put the quickest executing condition first.

isn't it put the most probably true condition first?

when choosing between

  A and B

and

  B and A

You want to compare expected execution times, which are:

  E(A) + p(A) E(B)

(E(X) =expected execution time of X, p(X) = probability that X evaluates to true) and

  E(B) + p(B) E(A)

The first is larger if

  (1 - p(B)) E(A) > (1 - p(A)) E(B)

End result is that it may be better to put the expensive call first, if the probability of the cheap call being true is much higher than that of the expensive call.

[Feel free to extend this model by adding the time needed to make or not make the branch around the second part]

In practice, if one is a function call and the other is not, put the function call last, then, if performance is inadequate, measure.

This is also one of those things that an optimizing compiler with profiler (or, equivalently, a JITter) can do. (I don't know if any compilers currently actually do so.)

You probably mean to put the probably false condition first, since if the first condition is false, the others are not tested anymore.

If the first condition is the slowest you can't get faster than that. But if the first is faster it might be the only one executed.