I think lendarios found a good solution. I'll have to try it out next time I'm in a clean code base to see how I feel. I think with some coding standards you do them for so long, seeing the light on minor shit like m_ isn't worth it because the light burns! Besides I have some 20 opinions of the author I disagree with so I want to move on. Hopefully you guys have the 20th debate about programming tests out of your system! (kidding).
Let's get this issue out of the way, before I even got the book I saw a handful of comments about one contentious opinion of the author: That functions should be very small. ex:
Bob_sl said:
The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.
...
Every function in this program was just two, or three, or four lines long. Each was transparently obvious. Each told a story. And each led you to the next in a compelling order. That's how short your functions should be!
The author then goes on to list some abomination code. I really like that the author uses real world code, especially code in well known and respectable products, ex Apache Commons. This code is larger than the typical samples I want to show, but it's the primary piece he uses and I think you need enough code to illustrate the idea. Plus I think this is the biggest problem I will have with the book:
The author describes many reasons why it's bad (repeated code etc), and then at the end of the chapter rewrites it to be how he thinks it should be with the information expressed in the chapter on functions.
I knew it'd be a challenge for me to get on board with the short functions, and after reading the chapter on functions that's pretty reinforced.
My primary contention with it is that when you use the Extract Method to take code out of a larger function and put it into a smaller function you add five new ways code can break: 1. declaration, 2. definition, 3. parameters, 4. return, 5. calling. In many cases the added simplicity of the calling function by extracting the details out are worth it. Often I'll drastically improve a nasty function by simply dicing it up into several new functions. However, when this is done in the extreme you get an explosion of new code and new points of failure.
My secondary contention is that when you pursue this your class explodes in the number of functions it has. You'll take a class with several functions and that can be quickly understood by looking at their declarations and change it into a class with dozens of functions and is now heavier. You may argue that you only need to look at public functions of a class to understand what it does, but when I need to work with a class I often need to know the private functions as well. You could argue that you should continue to use the extract method and have additional classes so you have a limited number of functions within each class. The problem with this is now you're cluttering your library with classes that expose details you didn't want to know about. This shit rolls uphill until you have a massively bloated library with an order of magnitude more classes than one would expect.
We actually had to fire someone several years ago who pursued this method. They spent a month on a week long project creating 34 classes where there should have been 4. Their code was completely unusable and thrown out with them. It had the same miniscule function content wrapped up into weak ass classes that all worked together like tiny ants wandering around carrying a popped kernel of corn in the grass. Trying to navigate your way through the code to figure out what ants did what and how they all worked was a disaster.
So following the author's example, here's my version.
There's a few things I could do to this, primary being to put it into a class like the author did. I wouldn't be against it, but it'd just exchange having to pass around the wikiPage/buffer for having to declare, construct and destruct an object. To me the added complexity isn't worth it for one function. If I had another html bullshit function I'd go that route. In a later section the author later admonishes the usage of function parameters like I did, but I'll whine about that later. There's probably other ways to improve it and it's not the perfect code, but IMO it's much easier to understand and fix than the bullshit he pumped out. It might also be wrong, so if you find a bug in it, get laid.
Now that I've gone through the exercise of unfucking this code, I regret selecting such a large sample (66 lines original, 86 of his refactored code, 46 lines of my refactored code), and I doubt many people will bother to read one version, let alone three. I also don't think it's necessary to have 50+ lines of code to discuss whether 3 lines of code is ideal for function content.
A quick note since I measured lines of code. Lines of code isn't a good metric for quality, efficiency or complexity. I didn't note the lines as some kind of evidence that my code is the best. 5 lines of garbage code are much more complex, error prone and worse than 20 lines of clear code even if they are functionally equivalent. However, in general I find that a lot of code can be improved by reducing the amount of code. Programmers, including me, often piss out lines of code that have copied code, spurious functions, circular logic (Ex: value = constant * k * parameter / k) and other stuff that bloats the code. An important part of the refactoring process is eliminating everything but what is needed to execute some functionality in a clear and concise way. When I see a huge list of functions to shit out some HTML, I feel like taking out a hatchet and cutting.
