He and I were both lamenting how hard it is to get team leadership to support the notion of small methods and classes, breaking long winded conditionals in to smaller routines with meaningful names.
I have noticed over the years that some people love small methods and classes, while others really don’t. Some people work better when more of the code is in one place rather than spread across multiple classes and methods.
Sandi Metz makes a great case for small classes and methods in her talk, All the Little Things.
I’m definitely in the small methods and classes camp. I’m not sure how that came to be.
It might be the things I’ve read, or it might be the way I learned.
Certainly some of it comes from being a long-time practitioner of test-driven development (TDD). Long methods and classes are just harder to test in most cases.
Some of it probably comes from being a Smalltalk programmer. As Adele Goldberg once famously said:
In Smalltalk, everything happens somewhere else.
However, even some Smalltalkers like to see more code in one place. Terry Raymond once created a tool he called a defactoring browser:
I am trying to create a defactoring browser. My plan was to use the inline method refactoring but to also keep the old line of code present in a comment.
The difference between a defactoring browser and the inline method refactoring is that defactoring browser would not actually change the method, just display the code differently so it is easier to understand.
Maybe a preference for longer methods and classes comes with a background in more procedural programming. I’m not sure about that, though.
Many years ago, in my youthful arrogance, I thought that people who didn’t like small methods and classes were just not smart enough to handle them; that they just couldn’t keep enough in their head at one time. However, I’ve met too many good developers over the years who prefer larger classes and methods, so I don’t think this any more.
Interestingly, Mike Dalessio just wrote a post, Abstraction, or, The Gift of Our Weak Brains, suggesting that the abstraction provided by smaller classes and methods is a necessity for people who can’t keep as much in their heads at one time. So, exactly the opposite of what I used to think.
What is it that causes some people to like small classes and methods, and others not to? I’m not sure I have a good answer, but here are some ideas:
Abstraction: As Mike Dalessio points out, abstraction is a big part of the equation. Small classes and methods abstract away many of the details of our code so that we can focus at a higher level. I think some people work better if they can see all of the details at once.
Naming: When you have small classes and methods, the abstractions have to be well-named. The names of these classes and methods must communicate what the abstraction contains or all bets are off. If the names are bad, then you are forced to drill down into the details all the time in order to figure out what’s going on. If someone has spent most of their time in codebases with poor names, they might prefer larger methods and classes.
Design: Similarly, the small classes and methods must be well-designed. Each class or method needs to represent a cohesive concept. If I can look at some code and say, “Oh, the external API stuff lives over there”, then I can choose to ignore it until I need those details. When the code is poorly-designed, it’s easier to wrap your head around if you can see more details in one place.
I think the fundamental underlying factor in all of this is Trust. Can I trust that the abstractions do what their names suggest, and only what their names suggest? If I can, then I have a better chance of working with the more-abstract code I’m looking at. If I can’t, then I’d be better off with larger classes and methods that keep more of the details together in one place.
What do you think? Do you prefer larger methods and classes or smaller? Has your preference changed over your career? What made the difference?