Coding: Naming
Sarah Taraporewalla recently wrote an interesting post about the importance of words with respect to the way that we use them in our code and it reminded me of some conversations I’ve had with Dave Cameron about the importance of creating a shared understanding of the different types/objects in the systems that we build.
On a few projects that I’ve worked on where we didn’t have a common understanding of what different concepts in the domain should be I noticed that there was a reluctance to make changes to class names.
Dave pointed out that this was probably because people have different maps in their head about what different domain concepts actually mean and changing class names ruins that map and therefore people’s mechanism for remembering what different classes do.
So how can we identify the real names?
If we can come up with a good enough way to name the types that exist in our system such that everyone has the same understanding then the mapping problem disappears.
Domain Driven Design suggests the ubiquitous language as a way to solve this problem, and while getting the language of the business into our code is the best way that I’ve come across for doing this sometimes it’s difficult to get this sort of access to domain experts to make it possible.
In that situation I think just listening to how we talk about the code is enough to identify problem areas.
Typically if a concept isn’t described by the name that it’s been given then the person will describe the actual concept in the words they use to explain what they’re actually referring to.
The neat thing about a ubiquitous language is that if we name things in such a way that everyone does have the same understanding then if we decide later that we need a new name by definition the new name will do a better name of describing an object than the old one.
Names are there to make it easier for us to talk and reason about code - if they’re not doing that then we need to change them until they do.
About the author
I'm currently working on short form content at ClickHouse. I publish short 5 minute videos showing how to solve data problems on YouTube @LearnDataWithMark. I previously worked on graph analytics at Neo4j, where I also co-authored the O'Reilly Graph Algorithms Book with Amy Hodler.