What's in a name? On unmasking dishonest code.
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.
getUsers()
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.
appleSauce()
The next step is to find something we know about the code, but stay honest by also including the incompleteness of the name.
parsesXMLToCreateUsersAndThenSomethingElseIsGoingOn()
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.
parseXMLToCreateUsersAndThenEmailThemAboutPasswordRenewalIfPasswordIsOlderThanAMonth()
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.
Offer
SAMMAN TECHNICAL TRAINING
Send your team to a course and some of them will remember part of it. Use the Samman method and they will apply what they learn from day one.
Book a meeting if you want to talk to me about technical agile coaching with the Samman method, to explore how I might help your team. I offer this for free, since I rather talk tech than do sales pitches. Let's explore if I can help you, by trying to solve your problems from the start.
Comment on the blog!
Create a comment by emailing me.
Open an email to start writing.I will then add the comment to the post.