There is a strong tendency among Java and C# programmers to prefix or suffix their extended types, such as naming a “smart” View
as SmartView
, or a Work
that is “delegated” as DelegatingWork
. In this post I will focus on decorators and how this widespread naming scheme reduces readability and adds no value to the code’s context. I think it’s time we retire this needless naming redundancy.
Milton, from Office Space
Composable decorators are small, highly cohesive objects that work off of another instance of their same type and thus are unable to function on their own. You can think of decorators as adjectives.
The problem with the traditional naming scheme is the needless repetition: we know from the outset that products
is a Collection
but the code keeps hammering this point home over and over again as we read on. This code is tedious to write, but more importantly, it is tedious to read, because of how the words are composed:
‘product’ is a filtered collection, a mapped collection, a joined collection, collection
Normal, every day speech is not encumbered like this; nouns are routinely omitted when sufficient meaning can be extracted from the context. You don’t normally say The rich people and the poor people
, you just say the rich and the poor
. Nouns are omitted and adjectives are nominalized.
Following this same principle, to make the code above read like this:
‘product’ is a filtered, mapped, joined collection
It would have to look like this:
I recommend we make our code terser by removing redundancy and allowing the code’s context to work in our favor for readability’s sake. For example, let’s use nominalized adjectives as names for our decorators.