Reading code that you are not going to change is mostly waste.
Arlo Belshee describes his Seven stages of naming in this series of blogposts. It is a method for reading by refactoring and it is awesome. Here I describe a tiny part of one aspect of it, in my words.
Arlo points out that our code is full of names that are nonsense, but dishonest nonsense. Names that look good, but does not represent the code hiding behind it. Those names are dangerous in a way than a “bad”, but honest name, is not.
It looks good, but if you don’t trust the code completely, you will still want to read the implementation. And if you don’t read the code, and the name is dishonest, you will break things.
Instead, turn the name into honest nonsense, like applesauce. At least that will not lure you into believing that you know what is going on.
The next step is to find something we know about the code, but stay honest by also including the incompleteness of the name.
Then we can slowly find out what the code is really doing. We figure things out, and save each piece of information as a part of the name. We do this until we have a name that can be read instead of reading the code.
That is a really long name. But I prefer long names to emailing people by mistake. Now I can see what the code does, without reading it, and the verbosity of the name tells me something else.
The names in our codebase can show the level of integrity the code holds, as long as we let them. Instead of trying to make the names in our code “look good”, we should use naming to make our design a tiny bit better, step by step. Then, eventually, the code will have good naming and deserve it. Remember, we don’t want to read code if we don’t have to.
If we let messy methods have honest and complete names, they will also guide our refactoring. More on that in a later post.
Comment on the blog!
Create a comment by emailing me. I will then add the comment to the post.Open an email to start writing.