Thursday, October 17, 2019 in Naming as a Process
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 together Deciding which abstractions best represent those clusters Picking a name that clarifies intent Picking a name that distinguishes from all the other similar intents Describing the side effects of the code Keeping your name under 15 characters This is why naming is hard.Wednesday, October 16, 2019 in Naming as a Process
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.Tuesday, October 15, 2019 in Naming as a Process
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 it Applesauce().Monday, October 14, 2019 in Naming as a Process
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.Sunday, October 13, 2019 in Naming as a Process
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.Saturday, October 12, 2019 in Naming as a Process
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.Friday, October 11, 2019 in Naming as a Process
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.Thursday, October 10, 2019 in Naming as a Process
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.