One line of code

One is the magic number. At least it is for two things when it comes to writing code.

The value of really small methods

The first thing one is the magic number for is the number of lines of code in a method. I first heard this from Brian Button in a TDD class he gave a couple years ago. He was talking with someone else and asked them what they thought the optimal number of lines of code in a method was. I think the other person answered something like 10 or 15. “Nope,” Brian said, “it’s one!”

One line of code per method! That sounds crazy! It sounded pretty far fetched to me at that time, too. But Brian is a smart guy, so I thought I would give him the benefit of the doubt and really try it out. That was a couple of years ago, and I’d have to say that I’m definitely a believer now!

Now, like pretty much everything in programming this is not a hard and fast rule. You have to consider context and use judgment like with everything else. So, I’m not saying every single method should have only one line. That wouldn’t work. I just mean it’s an ideal to shoot for. The closer you get to it, the better off you’ll be.

I’ve worked with people in the past who said they believed in “self documenting code.” What they really meant by that is: “I don’t write comments.” They didn’t actually write self documenting code, they just didn’t document the confusing code they wrote. If a class is 500 lines long and made up of a bunch of 20 to 80 line methods, it’s not self documenting. Just because you don’t comment it and say it’s self documenting doesn’t make it so. Creating self documenting code takes intentionality, thought, and effort.

One of the biggest things you can do to make your code self documenting is to break it down into small methods. Methods whose size approach one line of code. If you do this, you will understand your code better. The next person that has to read it will understand it faster. And with good method names, you will have real self documenting code.

As I’ve worked at coding this way over the last few years, I’ve noticed a few things. One is that when I have to go back to a class that I wrote with really small methods, I rarely have to spend much time at all remembering how it works. I find that I can understand how it works much faster than I could when I wrote classes with big methods.

I’ve also noticed my definition of a big class or a big method has really changed. I used to work on a system that had classes that where thousands of lines long with methods frequently being hundreds of lines long. Now when a class gets to 100 lines, I start really feeling like I need to break it up. And I am rarely willing to put more than about 5 lines in a method. Quite a change.

Another thing that I’ve noticed is that shooting for one line methods helps reveal a lot of code duplication. The other day I was writing a class, and I had all the tests written and the functionality complete. Now it was time to refactor. So I started breaking the logic down into smaller methods. As I did this I noticed that two of the methods actually had a lot more in common than I realized. I was pulling several of the same small methods out of each. Then I realized that if I implemented another method they both used a little differently, I could collapse both methods into just one line of code. This change lead to a 10% reduction in the size of the class due to code duplication. Duplication that I wouldn’t have even noticed, if I hadn’t been creating all those little methods.

So, writing one line methods may sound extreme, and it is just an ideal, not a rule. But if you adopt it, I think you’ll find your code is easier to understand, easier to modify, and contains less duplication. That’s a nice combination.

But wait, there’s more

There’s another thing for which one is the magic number. I read a blog post a while back that I wish I could find, but I search around and couldn’t find it. In the post the guy was saying that if you are creating a new class, API, or feature you should not consider it done until it can be used/called with one line of code! This is something I wish people would think about more.

When you are writing something, think about the code that will have to be written to call your code. Is there too much setup for even simple uses? Can it be called with one line of code? Again, this isn’t a hard and fast rule, but it’s something you should shoot for. Especially for simple things that people may want to do with your code.

For instance, say you have a file and you want to read the lines of the file into a list of strings. Now, that’s a pretty simple thing and should only require one line of code. Well, this is how it would look using java.io:

I suppose that’s not too bad. It’s only about 6 lines, but that’s a lot more than one. This is a simple and common operation, there’s no reason it should take more than one line of code. Of course, if you have Apache IO Utils on the class path, it is only one line:

That’s the way it should be. I don’t really understand what the designers of this API where thinking on this one. I guess they got so caught up in making a flexible API that can do anything, that they forgot to make it easy to use for simple things. They forgot to make sure it could be used with one line of code.

And don’t even get me started on JDBC! Oh man, what a pain!! Look, if I want to query the database with a couple parameters and get a string out, that’s pretty basic, that should only require one line of code. If it takes more than one line of code with your database framework, then get a new one. I don’t even want to think about how many lines of code it would take to do it with raw JDBC.

So, the moral here is, when you’re writing a class or an API, think about the calling code. Refactor and add helper methods if you have to, but strive to make your code as easy to use as possible for clients. Don’t make them write the same 3 or 5 lines of code every time they want to do something basic and common with your code. Aim for one line of code.

After all, one is the magic number!