Applesauce, Names, and Refactoring

Did you know that applesauce can be an important part of refactoring, understanding code, and honest function naming? It’s true, and here’s how it works.

First and foremost, I’m not talking about mashed apples. As much as I enjoy applesauce on my latkes, that’s not what I mean. I’m talking about using applesauce as an honest name for something.

Naming is hard. It’s one of the two big problems in computer science. Names are also a design problem. You don’t know what you don’t know, so names are fluid. As you learn more about the domain (by spending time in it) and the system (by building it) you find that the names you’ve come up with are often, to a greater or lesser degree, wrong. And as your understanding grows, your methods start to accrete more functionality. So you end up with a method called AddUser which ends up updating a user’s profile and sending email if they haven’t logged on in 3 months. At some point you realize that you need to refactor the code. You need to split things up in to methods that do one thing and that have good names.

The problem is that you often don’t know just how to split things up. If you don’t know how to split things up how can you come up with a good, honest name? You probably can’t. One option is to not bother to try, or at least not bother to try, at first.

Which is where Naming as a Process comes in. It describes a process that enables you to go from working code to working code while adding useful information to method names. And it starts with applesauce. You don’t know what the method does, when you should call it, what it returns, or even why it exists. Calling it applesauce is the first step on the path to a completely honest, informative, intentional, domain related name. You don’t know what it does, and unless you’re writing an app that manages a kitchen or food storage system no one is going to think the name means anything. So no one will assume it does the wrong thing. They’ll have to look at it to find out.

You started with AddUser, then you went to applesauce. If you stop there, bad developer. No cookie for you. But if you follow the process the name will get better. Next you make it honest, if slightly ambiguous. Look at the method. What does it seem to spend the most time doing? It seems to be updating the user’s profile, and along the way it will at least create the user if it doesn’t exist and send email if they haven’t logged on for a while. And maybe something else. There’s some more code that doesn’t seem to have anything to do with users or profiles. So give it a name like UpdateOrCreateUserProfile_and_SendEmailToInfrequentUsers_and_somethingElse. It’s a mouthful, but it lets you and anyone else looking at the code know what you know it does, at least one of the side effects, and that you’re pretty sure it does something else as well. It’s not great, but at least it’s honest.

Now start extracting things. Run the process a few more times until you’ve got a set of methods, each doing one thing, called by a controller that understands what to do. Give each method an honest name that explains what it does, like AddUserIfNeeded, SendInfrequentUserEmail, and UpdateProfileWithLastAccessTime. That’s going to be pretty helpful to the next person to look at it. Just by looking you know what’s happening.

Unfortunately, you don’t know why. That’s the next step. Make the name intentional and domain relevant. Move some logic around so the controller decides what happens and the other methods just do things. Things like CreateNewWebsiteUser, SendUserEngagementEmail, and RecordUserInteraction. All inside a controlling method called TrackAndEncourageUserAccess.

Next time you (or anyone else on the team) steps into the code they’ll see not only what is happening, but why it should be happening. They can trust that any side effects are made clear. You’ll all be happier. Especially if you’re the Maintainer