Being consistent in naming

Last Update: 08.11.2018. By Jens in Newsletter

Naming things like classes, methods or packages can be hard. Especially if you are not working alone. However, I don’t think there is a universal rule for naming things. It depends on the context. WHat comes close to a universal rule, is being consistent with naming. If you are working in a team and everybody on it names their classes and packages differently, it becomes a mess.

Same when methods have inconsistent naming, or, hell no, business domain objects & attributes have different namings for the same topic. The business calls it X and the devs named it y and z in the code. Mess assured. How do you even know you are talking about the same thing?

An example from today’s legacy code round. A Business entity name SeriesType, which has an ID aka code field and a few others. This type is used in a Product entity, but only by its id, which is a String. And the name of the field is groupingTypeCode… And both namings are now used in the code base. At least those two. Didn’t investigate further but its old code and there’s a high chance of a few more names for the same thing.

I’ve seen tons of these problems and believe me, it drives you crazy. So, be consistent, yep even through half-done refactorings. I’d rather prefer a bad name than a couple of name changes for the same thing in the code.

-