We all know naming is a pain in the ass and you can’t trust the names in your code. But it doesn’t have to be that way. Many people try to come up with a great name all at once. This is hard and rarely works well. The problem is that naming is design. Here are the things you are typically trying to do all at once while naming: Deciding the things the code should do Deciding which things go […]
What would it be like to trust names? Imagine a world where you read a name and you don’t have a read the method. The name is that clear. That informative.
Naming as a Process is a series of technical steps for a team or teams to adopt. This allows trust so now stories can be finished faster, there are fewer bugs, and interruptions are easy to handle.
Our recommendation? Read the series. Give it a try. Get your team to give it a shot. If you find it as effective as we know you will, drop us a line to see how we can help!
The two most terrible kinds of names are also the most common: Names that mislead you, and Important parts of something else, so they don’t even have a name. In the spirit of naming as a process, we want a quick way to fix these two problems. It needs to be trivially fast and light, so that we can do it the hundreds of thousands of times that most codebases need.
We have a thing with a name. But its name is obvious nonsense. One of my more gnarly experiences was when I worked within a system that spoke to the FAA’s system. This particular method was named PreLoad(), telling me when the system calls the method (not very useful). The problem is that there is a missing name. Nothing tells me what would happen on PreLoad(). Based on Article 2, I then extracted the entire body of PreLoad() and called […]
I need to make my name fully describe everything this method does. Each level of improved naming should record more insights and make it easier for the next person to read the code. This level actually makes it unnecessary for the next person to read the code. We want them to be able to trust that the name includes absolutely everything the method does so they can read and understand calling methods without having to read the method we’re fixing. […]
Congratulations on having a completely honest name! It is a huge step to simply represent exactly what the code does. All of the steps until now collected information into the name. In making the name complete, we have now made it possible to reason over the responsibilities of the class/method/variable without having to read its full implementation. This sets us up to change its responsibilities, so now we’re going to use the name to guide chunking the code. Part 1: […]
Every improvement in our name until now has focused on what our class/method/variable does. We made it honest and then we made it do exactly what we want. The name is both correct and clear. But it is awkward. We want to use this name to understand calling methods. It doesn’t yet serve that purpose. The name describes the thing. It doesn’t tell us why we care. That makes us stumble when reading the caller. We want the names to […]
Finally we are ready for the most important step in naming. This step is why all of evolutionary design really comes down to “name things well. Continuously.” It is time to correct the domain abstractions we are using and adjust the names. We currently have a set of names used together. Each one expresses Intent individually. Responsibilities are factored into the right places (each Does the Right Thing). But taken together, the names are a mishmash of ideas. Each expresses […]
Is your naming process effective for working with others? There are two hard problems that we face constantly. Naming Cache invalidation Off by 1 errors With naming being such a nemesis, it would be valuable to have techniques to make it easier. Naming as a Process describes those techniques. And (4 years later) I re-wrote my blog series and added a summary and learning path (this post) to adopt naming as a process. Why did it take me 4 years to […]