What Naming and Poetry Have in Common

What Naming and Poetry Have in Common
What Naming and Poetry Have in Common
Naming disputes should always be placed within a context. Otherwise, you cut out a ton of information necessary to choose a good name.

From time to time, I come across an article or comment that neglects the need for naming things, especially if that would imply creating a function that consists of a single line of code. Another, probably even more controversial, topic that pops up in texts like this is evaluating whether a certain name is good or not. One of those posts, named Do You Really Have to Name Everything in Software? , appeared recently on DZone and inspired me to add my few words to the discussion.

Problematic Example

//original, less clear code if(barrier.value() > LIMIT && barrier.value() > 0){ //extracted out to helper function. More code, more clear if(barrierHasPositiveLimitBreach()){

We see that the original author makes the case for extracting a one-line method with a supposedly meaningful name. It looked pretty good to me, when I first read it. The only thing that bothered me about this example was: Why can’t barrier own the method hasPositiveLimitBreach() ? The logic of comparing to the limit and zero is clearly related to the barrier. Maybe by moving the method inside the barrier object, we could avoid exposing the raw value, which is just a number.

In the article mentioned in the intro, the author initially claims that the problem is somehow related to structural and nominal typing. I don’t understand why he’d say so; my bet is that he wanted to show some SQL because that’s the language he really loves. After that, he provides a list of an opinion and questions that should supposedly act as an argument for not extracting the one-line method:

Now, which of the solutions would you opt for at this point?

The Missing Context

Although experience, knowledge, and other factors might suggest that one of the solutions is most likely better than the other, there is a huge part missing in the example for us to be able to effectively evaluate it – the context! It’s impossible to evaluate a name in software without knowing the context!

You might ask: Why is that so important? Because context carries around important information. Context is what gives names a specific meaning. If we had a context, the questions raised in the second article (chronologically) would be trivial to answer! Let me show you this.

Gaming Context In Action

The word barrier reminds me of all the MMO games that I played throughout my teens. So let’s suppose this is our context. We’re writing an MMO game and the barrier is a buff that you can cast on someone. Let’s get back to the arguments made:

As we can see, just adding the context reduced the problem to a single point: verbosity and intuitiveness. In the context of gaming, that name sucked, but a raw implementation would not be better either. What we actually needed was a name, but a better one.

Conclusion

This simple example was intended to show not only that a context is needed to evaluate a name, but that the context is required to choose a good name in the first place. With the context, we’re able to carry around a lot of information (look how many questions I answered just by specifying that the context is “MMO games!”) using a short, simple name. It’s just like in poetry – by understanding the author’s context – his life situation, age, country, political situation, etc., we’re able to derive a comprehensive understanding from a few short lines that might not seem to make any sense at first glance.

One final note: I took the comparison between naming and poetry from the excellent James Coplien’s presentation at MODELS’2016.