One of the things most of us encounter from time to time is bad naming in source-code. It could be a package, interface, class, method or variable, but when you have it in your system, it can irritate, or cause more serious problems like code duplication (DRY) and perhaps slowing you down. Even worse is a class with a misguiding name because people are put on the wrong foot, especially when they are new or not touching the code regularly.
That is why I take a step back and see if the name is intent revealing. In some cases a better name is found later (throw it in the team). And with all the refactoring support in new IDE’s, renaming almost always is not a issue and should be picked up asap. Especially when its a leaf in the system (something deep down) I do it immediately to reduce technical debt.
When the concept the name represents, for example a Listener, is used more than once in your system, make sure it is used consistently so you know what to expect. According to the timeless Unix philosophy this is called: ‘The rule of least surprise’. In some cases a good name depends on knowledge (e.g. perhaps you know it as an some kind of pattern), so a good name can be subjective. When it could be unclear to others, I add it to the documentation.
