Use-case driven naming

Last Update: 09.11.2018. By Jens in Newsletter

Besides being consistent with naming, I think readability and easy understanding are also important. I sum that up as use-case-driven.

An example from current work. Say, we have some kind of product configurator, where the user can select individual parts and a backend validates if this thing can be built. Each user selections is a constraint aka wish. Now imagine she can select a feature over multiple products like give me all Laptops with SSDs inside. Now, we highlight those products in a UI which fall out aka the constraints are not fulfilled.

So, in the UI we have the logic if unsatisfiedConstraints than set a CSS class somewhere. Do you call that method now isSatisFiedConstraint and use a !isSatisFiedConstraint when using it, or do you name it isUnsatisFiedConstraint ?

Sounds simple, but the wrong choice can make it hard to read and understand that code later. ! tend to be easily missed.

Go with the majority use, if that’s checking for unsatisfied, use the unsatisfiedConstraints, and if the other way is used more than once or outside the class /local scope, add equivalent method too.

And be aware when the use-cases changes due to a refactoring. I once named a method isNotOurURL which indeed checked if an URL is maintained by the system. Unfortunately, after some refactoring the main use case was to check if it is out URL, so the checks became !isNotOurURL. Yeah, deadlines :-) However, it drove my successor nuts and probably me too in the long run.

The compiler doesn’t care. But we do. It makes life easier.

-