Before diving right into the subject of naming, and at the risk of souding somewhat pedantic, an introduction is in order.
History show us that naming is so important to the human race that it’s being regarded as sacred (or at least) magical in most human cultures. Some non-exhaustive examples include:
- Judaïc tradition go to great lengths to search for and compile the names of God. In this regard, each name offers a point of view into a specific aspect of God.
- Christian Church gives a name when a new member is brought into the fold. The most famous example is when Jesus names his disciple Simon "Peter" (coming from petros - rock, in Greek). Other religions also tend to follow this tradition.
- In sorcery (or more precisely traditional demonology), knowing a demon’s true name gives power over it and let the mage bind it.
From these examples, names seem to bestow some properties on the named subject and/or gives a specific insight into it.
Other aspects of naming include communication between people. Not mentioning whether there are many Sami words for snow or not, fact is that colors are intrinsically cultural, some allow for a whole array of color names, while others only have 2 (such as the Dugum Dani of the New Zealand). Of course, designers and artists using colour regularly have a much broader vocabulary to describe colors than us mere mortals (at least me). In the digital age, colors can even be described exactly by their RGB value.
It’s pretty self-evident that people exchanging information have a much higher signal-to-noise ration the richer their common vocabulary and the less the difference between the word and the reality it covers.
Now, how does the above data translate into software development practive? Given that naming describes reality:
- Giving a name to a class (package or method) describes to fellow programmers what the class does. If the name is misleading, time will have to be spent to realign between the reality (what it does really) and the given name (what people think it does). On the contrary, right names will tremendously boost the productivity of developers new to the project.
- When updating a class (package or method), always think whether it should be reflected on its name. In the light of modern IDE, this won’t cost any significant time while increasing future maintainability.
- It’s better to have an explicitly incongruous class (package or method) name such as
ToBeRenamedthan one slightly misaligned with reality (e.g.Yellowto describe#F5DA81) so as to avoid later confusion. This is particularly true when unsure about a newly-created class responsibilities.
Let someone being much more experienced have the final word:
There are only two hard things in Computer Science: cache invalidation and naming things.