What Naming And Poetry Have In Common?

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 texts 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

The example discussed comes from another article on DZone titled: Using Java 8? Please Avoid Functional Vomit:

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 text 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:

  • The proposed name is verbose and requires quite some thinking.
  • What does breach mean?
  • Is breach the same as >=  or the same as > ?
  • Is LIMIT a constant? From where?
  • Where is barrier? Who owns it?
  • What does the verb “has” mean, here? Does it depend on something outside of barrier? E.g. some shared state?
  • What happens if there’s a negative limit?

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 text (chronologically) would be trivial to answer! Let me show you this.

Gaming Context In Action

The word barrier reminds me of all MMO games that I played throughout my whole 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:

  • The proposed name is verbose and requires quite some thinking – Yes, it is a bit verbose and it does require thinking. In the gaming context, we’d rather say  barrier.hasBeenBreached()  (or the opposite of that, if we’d like to keep the original meaning).
  • What does breach mean? To get it’s value (hit points) down to zero.
  • Is breach the same as >=  or the same as > ? Hell no! A barrier with zero points is useless, while a barrier with one point reduces the damage and maybe other stuff too!
  • Is LIMIT  a constant? From where? Well, this looked like a constant from the beginning, that’s the convention. Why does it matter where does it come from in terms of naming?
  • Where is barrier? Who owns it? It’s a buff on the player. Hard to say if the player owns the buff, but in a sense he “has” it.
  • What does the verb “has” mean, here? Does it depend on something outside of barrier? E.g. some shared state? I’d say in our context it’s related to “having” hit points left.
  • What happens if there’s a negative limit? The barrier is dispelled and the player receives damage.

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.

About the Author Grzegorz Ziemoński

King of Tidy Java, nerd that thinks about producing perfect software all the time and proud owner of 2 cats.

follow me on: