Discussion
As [Stroustrup00] §6's introduction quotes so deliciously:Premature optimization is the root of all evil. Item 6 and this Item). So is Bentley (see Item 9).We define premature optimization as making designs or code more complex, and so less readable, in the name of performance when the effort is not justified by a proven performance need (such as actual measurement and comparison against goals) and thus by definition adds no proven value to your program. All too often, unneeded and unmeasured optimization efforts don't even make the program any faster.Item 6). Clear code is easier to write correctly, easier to understand, easier to refactorand easier to optimize. Complications, including optimizations, can always be introduced laterand only if necessary.Item 7) and try to encapsulate and modularize the optimization (e.g., in a function or class; see Items 5 and 11), and clearly state in a comment the reason of the optimization and a reference to the algorithm used.Item 6.)Item 25), to prefer calling prefix ++ and -- (see Item 28), and use similar idioms that should just naturally flow out of our fingertips. These are not premature optimizations; they are simply avoiding premature pessimizations (see Item 9).