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.
magpiebrain 
5 Responses to “The importance of naming”
I’ve long thought that difficulty in naming something accurately and succinctly can be a very good indication that there is a problem with the thing’s very existence. A function or method can be very hard to name accurately and succinctly if it does more than one thing, for example but then, a function that does more than one thing should be split into more than one function. The same applies to classes, variables, you name it.
I kind of agree. If you have a problem naming something it tends to be either because:
* You don’t have an adequate vocabulary (fairly rare)
* You don’t understand what your doing enough to give it a name
In the second case, if you don’t understand exactly what the code is supposed to do, then why are you doing it? Oh, and a minor woho! – this is the 300th comment…
I agree. Naming is hard. But I have this bad habit of trying to get things perfect before starting things so I’ve been experimenting with refactoring techniques to keep things moving. I let myself permission to get the name wrong. It’s tough for me to do this. I keep convincing myself, “I’ll refactor this later.” In the name of progress, I plod on.
Other approaches I’ve seen:
* nonsense words, e.g. “fargle”
* generic naming, e.g. “doit”
* frozen naming, “print()” when the function no longer does any printing.
One thing that could ease the stress of name changing would be to decouple the method and class names from the implementing methods and classes. Kinda like COM uuids. Or even go farther and have the platform support some sort of interface specification which is a hash of the entire interface including all signatures. Kind of like language support for the automating the Adapter Pattern. hmmm, perhaps something like that is already possible through dynamic proxies …
Another bugbear of mine – redundant naming. The current project I’m working on has lots of this – things like a class called @Catalogue@ with methods like @catalogueName@, @catalogueItems@ etc.
Ooooh! Ooooh! Check out Naming Classes – Do It Once And Do It Right[1].
[1] http://www.hacknot.info/hacknot/action/showEntry?eid=48