> How many functions are good? As many as needed. > If I add a dozen, is that better? If your programs path needs to do 12 things, then yes. Each function s

> How many functions are good? As many as needed. > If I add a dozen, is that better? If your programs path needs to do 12 things, then yes. Each function should do one thing. If in documenting your function, you use the word and, that's a safe bet that you are actually writing two functions as one. > Short methods are good—have any evidence for that? I don't think you do, because such evidence as there is points in the opposite direction (look it up in Code Complete) Unless there is another reference I missed, Code Completes reference referred to no more than a screen's height, which at that time was ~ 25 lines. Assuming not every line is a line of code performing some action, I'd still consider that a small function. > It's proper to name functions properly? I agree! What's "properly"? That's hard to answer, which is why so much has been written on it. Couple that with community idiosyncrasies (like Obj-C naming vs Java), you have a lot of "proper" ways to define functions. Within the realm of the community standards, I subscribe to the thought that the method names should tend to be verb oriented. Talk about actions, or perform an action. After all, functions do something. > We have almost no empirically verified knowledge about software development. Well, there is quite a lot. Much of it's older (in the history of software). > One of the few things we do know (sort of—the studies are old and shaky) is that code size is a predictor of error rates. Think that's relevant? Be careful about this. It's not as open and shut as you'd like to think. Indeed, it's about as verifiable and confirmed as cyclomatic complexity is. Without going into too much detail and sticking strictly the context here: "code size" is an awful metric. By that notion: int a = b + c; Is dramatically better than: int hours = timesPerformed + hoursPerPeformance; Layer that into the concept of lines of code: is that lines of functional code? Lines of any code that isn't a comment? Any lines that aren't a comment? Lines of code that are only functional? All lines, including comments? All lines, including comments, except for standard headers? All of those are valid deductions. After all, while it might seem obvious to remove comments, they could cause confusion, right? And this ignores even the basic question: is a line merely a line on the screen? Or is it a languages statement? A single operation? Would a complex for clause with multiple assignments and statements count as one line? All this is to say that code size is not the holy grail of error rates. My own though is that taking CC and LoC and putting them together is best. A function with low complexity and with fewer lines of code is better than a longer function. Many smaller, lower complexity functions are also better than a single highly-complex function that is longer than any single function, but smaller than all the others when combined.