Avoid Meaningless Terms
| » | class MainSpaceShipManager { |
| | AbstractRocketPropulsionEngine abstractRocketPropulsionEngine; |
| | INavigationController navigationController; |
| | boolean turboEnabledFlag; |
| | |
| | void navigateSpaceShipTo(PlanetInfo planetInfo) { |
| | RouteData data = navigationController.calculateRouteData(planetInfo); |
| | LogHelper.logRouteData(data); |
| | abstractRocketPropulsionEngine.invokeTask(data, turboEnabledFlag); |
| | } |
| | } |
Good naming isn’t just about spelling out short names and making names longer. Sometimes, long names can be just as burdensome. And there are some terms programmers use often that have lost all meaning.
Look at the code above. It doesn’t contain abbreviations like in Avoid Abbreviations, and all names are spelled out, but that doesn’t mean the naming is good. There are various meaningless words in there that you can just remove. And we’ve seen names like this many times in real production code.
Can you spot which words convey no meaning and just add text? What parts could you leave out without impacting understandability?
There are some low-hanging fruits—meaningless terms that people use very often, like “main,” “manager,” “data,” “info,” or “flag.” They’re easy to spot. But what about the terms “abstract,” a method named “invoke,” or a parameter’s type within a method name? Are those meaningful? Not really.
So what parts can we leave out without losing the intended meaning?
| » | class SpaceShip { |
| | Engine engine; |
| | Navigator navigator; |
| | boolean turboEnabled; |
| | |
| » | void navigateTo(Planet destination) { |
| | Route route = navigator.calculateRouteTo(destination); |
| | Logger.log(route); |
| | engine.follow(route, turboEnabled); |
| | } |
| | } |
Actually, we can leave out a lot. Just compare the two code snippets: we removed over 100 characters (about a quarter of the whole code). That’s a lot less to read and think about. Not bad! Let’s go through it.
To start with, we simply removed typical meaningless terms like “data,” “info,” or “flag.” It’s rare that such terms add any meaning to the code.
Next, when reading a type name, we don’t care if it’s an enum, a class, an interface, or an abstract class. After all, the type itself is already stating this. That’s why the term “abstract” or “impl” doesn’t help in class names, and neither the prefix “I” for names of interfaces. Don’t do this!
A class’s name provides context to its members and already conveys a lot of meaning. That’s why you can remove domain specifiers like “rocket” in a class named “SpaceShip.” You can do the same with repeated parameter types in method names, as in logRouteData(), which we renamed to log(). The parameter route itself already states what’s being logged—no need to repeat it in the method name.
Verbs like “invoke,” “call,” or “do” also convey little meaning in method names. Instead of using these, you should try to find a more precise and meaningful verb instead. Lastly, we often see meaningless terms in package names as well. Watch out for words like misc, other, or util.
Our advice is to watch out for the terms mentioned here and to think twice whenever you feel tempted to write them. Whether a term is actually meaningful or not depends on the concrete context. Many frameworks have a hard time deciding this as well. One class name in the Spring framework is famous: Roses are red, leaves are green, but only Java has AbstractSingletonProxyFactoryBean.[33]