ExecuteBrainHero() factoring

This is not a very significant thing: The explanation Casey gave for factoring the code for executing a hero brain out of ExecuteBrain() was that it had grown large. However, I have heard him and others say that this is not a valid reason on its own to factor out code. It seems to me that ExecuteBrainHero() does not want to be called anywhere else and the purpose of the code was well documented inside ExecuteBrain() by the switch on the enum.

Can anyone explain to me, why this factoring was the right thing to do?

Edited by Benjamin Pedersen on Reason: Initial post
I believe "large" is a subjective thing. Everybody has their own feeling or definition what is large. It comes with experience (basically writing lots and lots of code) to optimally judge when function is "large" and when to split it or not. You'll just get a feeling when its time to split the function :) By saying "splitting code because function is large" people usually mean that you should not use just the count of lines in function as a reason to split. Because sometimes you'll see in coding guidelines/rules that "function MUST never ever be larger than 100 lines".
Benjipede
Can anyone explain to me, why this factoring was the right thing to do?


The notion that there is such a thing as, "the right thing to do", is 100% false.

Two equally advanced expert programmers will (more often than not) have two totally different approaches/criteria for organizing chunks of code into functions. One guy's brain may work more efficiently looking at large uninterrupted blocks of code, while another guy does better breaking everything up into tiny functions. Take Casey's coding style for example it's extremely verbose and doesn't value vertical space compared to what you'd expect to see in more conventional high quality C-like code. But this is his style, it's what he's most comfortable and presumably most efficient at. Or to use probably the most extreme example, check out Ken Silverman's build engine.

Breaking up code is really about minimizing the complexity of your program for yourself. And you can't really just tell someone how to do that, it's more of a hard-faught wisdom kind of thing that follows naturally from experience.

Edited by NelsonMandella on