One of the few benefits of a long commute, is the fact that I’m not doing it alone. The time afford to me each morning on the train to and from work also provides and opportunity for discussion on all kinds of topics, ranging from the poor state of journalism in the daily free newspaper the Metro, to some more esoteric issues at least tentatively connected with work. One discussion which fell between these two concerned the notion of naming – be it the naming of classes, methods or packages.
One of my colleagues asserts that naming is actually one of the hardest things he has to do as part of his day-to-day development. I agree tentatively with that statement – however the problem is not a lack of vocabulary, more that when naming is a problem we often just don’t understand what we are trying to name. The more we mentally consider the code to be an amorphous blob, the more naming becomes difficult. Once our understanding of the code coalesces into something more concrete, naming often becomes trivial.
To some extent the widespread understanding of common patterns has helped this issue. Patterns are nothing other than names given to used and well understood problem solving techniques – it gives developers a common vocabulary to communicate with (hence my disapproval of people who rename patterns), and gives us a an immediate root naming convention to use for many of our classes). In fact by being able to look at the name of a class and immediately recognise it as part of a pattern-based solution, the naming has imparted understanding of the design. It then becomes doubly important that we are using such phrasing in the correct manner. Think of class and method naming as the first impression a codebase makes to the developer. From it, we start to make some initial assumptions about what it will do – if the code doesn’t back up this initial impression then confusion can reign supreme.