Code Smaller

blog
21

“The world is not linear” – Donald Hughes McElhone/1976

No, you won’t likely find him on Google. I just worked for him. Bug count and line count are closer to geometric.

That said, since I’ve been living in Big Iron land for the last few years, a significant body of “new” code in Enterprise land (java, anyway) is replicating its COBOL grandpappies. In this land, programs are as large as the z/OS footprint will allow, since runtime cost is all that matters to these folk. They’re wrong, of course, since these codebases change as often as any other. But they focus on Glass House charge back $$$, solely.

And OO hasn’t been the Nirvana of plug-in objects either. Has it?

22

with a little modification, Steve Jackson’s comment reflects my own thoughts on code quite nicely:
“I love small classes and methods, but I [am always] looking [for a] big picture, where do I start. Where’s main? Does anyone have any suggestions on how to handle both sides of the picture? Make the code small, self describing, and maintainable (like legos), but still be able to step back and see the tie fighter? I feel that much of my code is very flexible and can be used in ways that were never intended, but what good is that if I’m the only one that can understand what the jigsaw puzzle looks like [when I’m done with my code]? …
Steve Jackson on February 15, 2007 09:08 AM” – emphasis, replacements and ellipsis are Dominick’s.

23

Hello,

When I first started developing I was introduced to the self-encapsulating class that knew way too much about itself and the world around it. Since I work primarily on web applications which is a mostly a state-free environment, it didn’t make a lot of sense to continue to build those kinds of classes.

I eventually caught on to CodeSmith and began customizing templates to generate a entity/collection/manager class set for each database object. This method has saved a lot of time and make my code more agile. If you are interested, you can download the templates I use from my site.

http://tod1d.net/files/default.aspx

24

If it’s too big to readily understand, it’s too big.

25

I grew up on COBOL, then Pascal and some other procedural languages. Functional Decomposition into manageable chunks with internally consistent levels of abstraction was my favorite way of breaking large rocks into small rocks. FD still shows up sometimes when breaking a longish method into more self-descriptive parts. But OO is really a whole other way of breaking big problems into little ones. Dependency management, always the main point of modular design even if we didn’t know it, comes to the forefront for good OO fun. When methods are too big, it often means the class is too big. The more a class knows and does the more dependencies it gains on the things around it. The big ball, indeed.

26

Who said “modularizing code is against optimization” ? In C, if you really feel like you need THAT type of optimization, you can just use inline functions, while keeping the code readable.

27

First of all, the whole point about too many methods, functions or classes is right out.

A compiler absolutely should optimize out all those calls to just leave the meat of it. If yours doesn’t, try Java. Also, ALWAYS go with the first expert rule of optimization, don’t optimize for speed until you’ve written the best most understandable non-optimized code you can–and that means the smallest.

It really blows me away that people can argue with the most common, basic facts of software development. It’s like an architect arguing that straw makes a better building material for high-rises.

We solved the problems long ago, if you don’t like the rules–go study, the rules aren’t wrong.

-Small methods, small functions, small objects and small files are more understandable and usable (good).
-Documented code is good.
-Any repeated logic anywhere is bad.
-Too many interactions between entities is bad.
-Variables that can be modified outside your currently displayed file (globals/publics) are bad (Actually just the worst case of the previous point).
-There are many others.

There are many fine points in our line of work that you can argue over, but if you find yourself arguing against one of these, please reconsider. If after consideration you still believe you are correct, please find another line of work–for all our sakes.

Remember also, The primary user of your code is the next programmer, not a computer–otherwise you’d just throw away the source and keep the object code.

PS:
To the people who had trouble because his small classes weren’t understood:

Small classes are no harder to understand than large classes. I hate to say this, but consider that you should work on your communication ability (I always feel it’s my fault if I can’t download a concept from my head into someone else’s)

Even before you code, you should be able to visualize your main classes or functional units and the relationships between them. If you have more than 5 small “core” classes, draw them on the whiteboard before you start coding. Eventually this should make it onto some form of paper. I’ve photographed whiteboards and created in-depth UML diagrams, but the whole point is to come up with whatever is necessary to communicate your structures to the others on your team.

What your users want to know is what are these core classes and how do they relate; this is exactly what class diagrams were created for.

Coding the small classes is easier for you to understand, so if it’s not easier for the rest of your team to understand, bridge the gap and do whatever it takes to communicate.

This communication ability is what separates a senior programmer from a Junior.

28

At risk of being labeled just another Goldilocks: both small for the sake of small and big for the sake of big suffer from the same coinage, both sides.

small: not enough context as you scan, so your memory has to track it
big: too much context as you scan, so your brain gets overwhelmed
just right: well, yes

It’s been a while since I’ve invoked him; just go read Allen Holub, you’ll get an OO perspective that gets beyond get/set. You may not like what he says, but an honest rebuttal is not a trivial thing.

29

Jeff, thanks for this post, but I find it extremely sad that this even needs to be stated.

30

How does one judge when a method is too long or too complex? Cyclomatic Complexity is a metric that can be used to help determine when a method should be refactored into smaller units.
Tim Binkley-Jones on February 14, 2007 08:47 PM

Tim,

Cyclomatic complexity is a useful measure but here are a few guidelines that I use…

  1. A function should express a single step of operation at its level of abstration. Basically it should do one thing.
    This is hard to understand sometimes but is “I know it when I see it” sort of zen state. If the function is doing several things, each of those things should be be refactored into individual functions.

  2. A function should fit one one screen.
    There are exceptions, like very long switch statements or long blocks of initialization of arrays and the like, but logically these of just long homogenous blocks.

  3. Redundant code should be a function.
    Cut-and-Paste is the duct tape of coding. Handy but don’t use it to build sky scrapers. Redundant code is a bug waiting to happen.

  4. If you can’t understand it when you look at it next week, it is unclear and needs to be refactored.

31

I’ve been living under a rock. Never heard of it.

Ahh…no wonder. PS2 game. I don’t pay attention to the PS2 scene.

Oh good, versions coming out for the Wii and XBox360. I have neither of those (do have an XBox) either. I may get a Wii, though.

Perhaps I’ll check it out then.

32

I apparently live under a rock. I’d heard of Katamari but never knew what it was.

Here’s a video: a href="http://www.youtube.com/watch?v=cwhFH75OCDs"http://www.youtube.com/watch?v=cwhFH75OCDs/a

33

I love small classes and methods, but I work with a lot of people who have a hard time grasping things that are very small. They’re looking big picture, where do I start. Where’s main? Does anyone have any suggestions on how to handle both sides of the picture? Make the code small, self describing, and maintainable (like legos), but still be able to step back and see the tie fighter? I feel that much of my code is very flexible and can be used in ways that were never intended, but what good is that if I’m the only one that can understand what the jigsaw puzzle looks like? I’m not sure detailed design docs or anything else are a big help (been there, tried that), plus they slow you down when you have to add gobs of documentation each time you refactor something into smaller more maintainable piece.