> If a function is only called from a single place, consider inlining it. Funny because it's backward. If a code is duplicated, consider to make a function if

> If a function is only called from a single place, consider inlining it. Funny because it's backward. If a code is duplicated, consider to make a function if the pieces of code are the same semantically. (Two pieces of code which are the same at a given time can diverge over time and you don't want to miss that. Only analyzing the sense of what you're doing (=semantic) gives you the answer.) Never add fancy things (like adding a function which is not a function) in your code because code is not fancy, it causes bugs. > If a function is called from multiple places, see if it is possible to arrange for the work to be done in a single place, perhaps with flags, and inline that. Well yeah, fix the semantic if it needs to else do nothing. > If there are multiple versions of a function, consider making a single function with more, possibly defaulted, parameters. Well yeah, fix the semantic if it needs to else do nothing. >Minimize control flow complexity and "area under ifs", favoring consistent execution paths and times over "optimally" avoiding unnecessary work. The right thing to do is to never optimize unless it's to slow and you've identified the first bottleneck. "Never optimize" means: write the naive code correctly (without performance aberation like adding element in an array). > To sum up: Stop fancy. Stop optimization. Stop thinking about code syntactically (=the succession of operation gives the good result). Think constantly about your code semantically.