Simplicity *does* mean simple, readable methods
Following a link from @raganwald I came across an article where Mike Taylor was debating wether the concept of simplicity, as it pertains to the length and complexity of methods isn't subjective. He read a decent chunk of Fowler's Refactoring, found himself disagreeing with the tendency to composable, well named methods, in favor larger methods with the low-level implementation in the method itself, and hoped maybe he was wrong, because the lure of The One True Way is strong. While I am often a subjectivist, as I told my fiance, "Honey, somebody on the internet is wrong - I must inform them immediately."
Basically Mike breaks it down into two approaches: top-down, where the methods are named what they do and abstracted away so you don't see each step of implementation at the top, and bottom-up, where the main method is a little larger and is built up of the implementation itself. He favors bottom-up, and I am a partisan of the other camp, as rubyists often seem to be.I think there is one most important reason to favor the big-picture top-down in this dichotomy. From top-down you can dive down into the implementation and see the details if you chose, but in bottom-up there is no way to get the equivalent top-down view without just reading and understanding the whole program. Basically, advocating the bottom up approach is like making world-maps illegal, because you can get a better feel for navigating your hometown with a city-map.
From this flows the second most important reason, the inability to mentally page out to disk, so to speak, means you have to hold more of the program in your head to understand what is going on. That means as the program grows in size, it gets harder and harder to keep track of it all. And the reason this is really a problem, is when it comes time to introduce new people to the code. By not abstracting things away into bite-sized chunks you've just forced them to learn every piece of everything involved to have a hope of understand things enough to actually get any work done.
A third point: various software engineering theories like: cyclomatic complexity and single-responsibility principle.
I will admit that getting carried away with classitis and class hierarchies, Java style, has some cost, when it comes to following what a program does. There is a little balancing act required there. But, I do think, that decomposing methods is an unequivocal win. I think Rein's tongue-in-cheek talk on Unfactoring is a better visual, code-based proof of the importance of this for maintainability than anything I could whip up here (about 5 minutes in he gets into the examples).
Lastly, who hasn't gone back and looked at their old code and wondered what they were doing? If you want to go back and tweak something, it's painful if you have to refigure out every piece of implementation. This is a case where scanability and readability is a huge win.
Comments [10]
