Here’s an old blog post of mine, originally published June 6, 2009, that I though worth revisiting today:
I came across a great blog post yesterday by Robert Nystrom, Naming Things in Code. Robert goes through a whole bunch of examples and comes up with some rules for how things should be named. Here’s a an oversimplification:
- Type names should be nouns
- Functions that do things should be verbs
- Functions that return booleans should be questions
I don’t want to reproduce his article here. I want you to read his article.
I’ve thought for a long time that the way things are named in code is one of the most important decisions a programmer can make. I’ve also discovered that when you’re “in the flow” of creating something, stopping to decide the best name for something can be an interruption and can actually hurt your code.
Sometimes, you know you need to store some data in a temporary variable, for example, but you’re just not sure what to call it. So either you break your flow to stop and think up the right name, or you call your variable “X” and you move on.
This exact scenario is the reason that the first refactorings created in Castalia were the simple “rename” refactorings. In my opinion, the essence of refactoring comes down to two things: 1. Renaming things, and 2. Extract Method. The whole point of both of these is to take code that you know should be organized better and to make it really easy to organize it better.
So when you realize that X should really be called “AverageUnits,” you can use Castalia Refactorings to change it with just a few keystrokes and move on, with no tedium and with no impact on the way the code works.
The point? More readable code is better code.