WhyITakeTheTimeToNameThingsPreciselyEvenThoughThoseNamesCanGrowQuiteLongAtTimes

I recently coached a few teams in modular design and test-driven development and, in the process, made a small change to the way I explain the Four Elements of Simple Design. Specifically, this concerns the point where I suggest that people focus on removing duplication and fixing bad names.

When I give people long-range, culture-change, you-have-to-figure-it-out-on-your-own advice, I believe I also owe them some follow-these-rules, you-can-start-on-Monday advice. While I believe most people easily get started removing duplication, fewer understand how to start fixing bad names, because to fix them, you need to know specifically what to fix and specifically how to fix it. I wanted to give these people some practical advice on improving clarity in their code base by improving names. I settled on this advice: make names more precise.

Before I continue, I leave it to you to investigate the difference between “accurate” and “precise” since, even today, many people confuse the two. If you can’t rattle off the difference between these two words in the next ten seconds, then please look them up. Thanks.

Making names more precise, whether for variables, methods or classes, helps me identify emerging structures in my design. Patterns in names call my attention to smaller structures trying to burst out of larger ones. I can give you a few examples of the patterns I see.

  • While extracting methods, I see many private methods with the same word or phrase in the names
  • I extract a method whose name matches, at least in part, the name of one of its parameters
  • I extract shorter methods from a long method and see that the long method invokes the shorter methods in recurring groups by their names
  • I extract complex expressions into variables and find similarities in the names

Each of these merits an article on its own, so I will defer the details until then. In each case, naming things precisely helps me see the emerging pattern and even helps me name the emerging element, whether new methods, interfaces, or classes. Vague names simply don’t do that.

Please reflect on this question: why do you name things vaguely? What tempts you to name something “compute” or “execute” or “do” or “go”? Why not simply name things as precisely as you can?

I’ve seen and heard a variety of answers, ranging from I don’t want to type that much to Names shouldn’t run 60 characters long to I really don’t know. I conjecture that people pay less attention to names because they don’t see a concrete benefit to making names more precise.

Designers talk passionately, but vaguely, about so-called maintainability or readability without articulating what those words mean. Those designers might know for themselves what they mean, but unless they can explain that meaning to others, they rely on each person’s innate pride in work to name things well. Sadly, hope in the innate pride of workmanship in others doesn’t scale to great designs in large systems. Let me, therefore, articulate a concrete benefit of naming things precisely.

When I name things precisely, I more easily see when similar things are far apart and different things are close together, both signs of poor cohesion. When I name things precisely, I more easily see duplication in the intent of blocks of code, and can more easily remove that duplication, resulting in fewer potential defects. When I name things precisely, I more easily see patterns in names of private methods that suggest too many responsibilities in one place, and when I split those responsibilities, I decrease the coupling in a system. I know that I should fix problems related to low cohesion, high defects and high coupling, and naming things precisely helps me find those problems more easily.

I hope these guidelines help you in your designs.

14 years ago
Comments
blog comments powered by Disqus




Blue Theme by David