Naming

Naming is hard. It is the beginning of all confusion and laziness in code, and it is usually where most bugs hide. If the code is littered with bad names, you should be very suspicious of it.

Oddly, the hardness of the problem is because people expect it to come easily. So they get frustrated when it doesn’t. Then they just cheat and use really bad names instead.

As people see other people’s badly named mistakes, they accidentally follow suit, so the conventions really tend to degrade with each generation. And since they are mistakes, it becomes even harder to understand why they were chosen, making it all even more confusing.

But naming is an explicit indication that you understand what you are doing, and that you think about it clearly. The two most important characteristics of good programmers: the mechanics are clear in your head (unique) and you understand what is happening (precise). With those two things, most names, most of the time, are fairly obvious. If you also understand the degree of generality you need, then you know how to properly lift the names as well.

How do you know if the names are bad?

Easy. Go verbally explain your code to another programmer.

If your names are self-explanatory, you will use them directly while you are talking. If each name needs a description, explanation, or some other help, then they are bad. More to the point, if what you are trying to do needs any overly complex explanations and those explanations cannot be directly abstracted away in one step from the work itself (e.g. objects, models, patterns, idioms, data structures, etc.), then the whole thing is messy and convoluted, and likely does not work in the way you expect it to.

Because naming is hard but fundamental, it is one of the core skills that you should work on developing very early in your career. If you wait until you’ve learned other stuff first, your naming habits will be so poor that the stuff you produce won’t work even if you know how to do it properly.