subscribe via RSS
This post is a comment on a few things from an amazing blog post by Peter Hilton on Naming Smells. It describes multiple types of naming problems and suggests how to fix them.
Short and Symbolic Names
My favorite post parts are about short and symbolic names. I think they explain why so many of us run away from math theory after seeing the first formula. The same feeling I have about most of the things in academia - things look cryptic. What makes me sad about it is seeing the same cryptic naming patterns cripple functional programming communities. And I think it is a number one reason why we are so bad in adopting functional languages. It is not the category theory that scares people away, but how we communicate it in our code.
Prefixes May Have Meaning in Boolean Properties Naming
One place I do not fully agree with the author is dropping prefixes like
the names. In general, what I really like about dropping prefixes is that it
makes us think more about the meanings of our names. Dropping prefix from
renames variable into
victory, which on its own has a broader meaning.
It can be an object with much more functionality than very limiting boolean
type. If I ask “is victory”, I’m used to get “yes” and “no” answers.
If I ask just “victory”, I am not sure what it can answer. “yes”, “no” or maybe
“in progress”? In type-safe languages we have types to communicate this meaning,
but I see types more as tests which compiler runs, and not a tool to improve
readability. Type information in a lot of cases is one or more steps away from
the reader (even with an IDE provided shortcut). There can be good uses of prefixes
to emphasise intent of the variable. For example, prefixes like
bring their own bit of information into the name. If dropped, this meaning is
lost. I would say don’t follow this rule blindly. If you cannot come up with
a good name, stay with a prefixed one. If you can give a good name without
prefix - go for it. Good names must be explicit.
Give Specific Names to Variables
I like to be very specific in collection variables naming. Blog post contains
a part on multiple words naming where
appointment_list is renamed to
In my understanding a calendar can mean more than a list of appointments.
For example, it may hold properties like name, owner and maybe some other information
like reminders. I usually name lists as plural forms of items they contain.
In this case it would be
appointments. Another example is where
company_person is renamed to
employee. I think this one is very good
naming example. Why is it good? It is shorter, contains more information.
For variables specific names are better, while generic names are worse.
It may not be the case for types naming, where reusability drives to have more generic names.
It is very easy to find counterarguments for every good naming practice if it is done outside the context where name has its meaning. Removing code smells without understanding why something is bad, may do more harm than good.