It's hard to discuss in the abstract, especially with bad names like MinorFunction1() and MinorFunction2(). In style C, you may have to scan over lower levels

It's hard to discuss in the abstract, especially with bad names like MinorFunction1() and MinorFunction2(). In style C, you may have to scan over lower levels of abstraction than you care about: MajorFunction() { // fast inverse square root float x2 = number * 0.5F; float y = number; // several more lines of code // find decimal point char *c = input; while (*c && *c != '.') ++c; } A goal of style A or B is for the names of the minor functions to make the shape more obvious, ideally self documenting: MajorFunction() { y = Q_rsqrt(number); char *c = strchr(input, '.'); } This is the kind of advice you'll find in, say, Code Complete. Although I generally accept the premise, there is a readability cost to indirection. The bigger and more complex MinorFunction() is, the more likely I'm going to have to jump into it and remind myself what it does. There are two concepts that underlie DRY: coupling and cohesion. There are good expositions on this in old writings on structured programming and design (e.g., Yourdon and Constantine). If MinorFunction() is cohesive, and MajorFunction() is appropriately coupled to MinorFunction(), then style A/B is likely to be superior to style C. One of Carmack's points is that "very little of our real code" ends up that way.