What's in a name? If you're a person, it's there to establish your uniqueness within the community you live. If your name is Frank, and your father's name is Frank, then there's usually a Jr., Third, Fourth, etc attached to the end of your name so the people in your household know how to call which one of you down to supper. If you went to school with someone who had the same first name as you, it was often common for people to use your last name, or some abbreviation of your name to tell you apart. Your name establishes you as an entity.
If you lived back in times not too far gone, say starting around 10th or 11th century AD, your last name (surname) would typically describe one of
four things about you:
1.) What you and your family did for a living. The Coopers were barrel makers. The Wagners were wagon makers or blue fuzzy teleporting mutants....
2.) Who your father was. Johnson, Peters, Myers, "The Mailman", etc.
3.) Something about your locality. The Ashley's lived by ash trees (not set on fire, or maybe they were, I'm sure some Ashley's were cremated at some point).
4.) Nicknames. Reid's were the redheads, the Armstrongs had strong arms, and the Cox's had...um...
You can even trace your family line back hundreds, if not thousands of years based on nothing more than your name. The point is, names are important. They help define us, and what we do.
The names of your variables, classes, and methods are no less important. In fact, they're probably more important, because they have no visual features in which to distinguish themselves by. They give context to your application. Well named objects help you define how your application works just like putting the correct words in the correct order helps someone read a book.
Naming is so important, that
Steve McConnel dedicated 32 pages to just naming variables in chapter 11 of the foundational book "Code Complete", plus even more pages for naming methods and classes.
Example time. Which set of variable names are easier to understand:
numBckWLinFtTtl01, numBckWLinFtTtl02, numBckWLinFtTtl03
or
standardStoreBackWallLinealFeet, prototypeStoreBackWallLinealFeet, remodeledStoreBackWallLinealFeet
So what's wrong with the first set of variables? Other than it used to be in use in one of the legacy systems at my company.
- Uses a form of Hungarian notation (putting type information, along with other prefixes) into variable names. The truth is, there's simply no need to do this anymore. With modern IDE's, all it takes is hovering over your variable to get a tooltip telling you what type it is. All it does is add more letters to the front, that developers have to train themselves to ignore, so they can get at the real info
- The abbreviations. Cripes. If I had a nickle for every time I've touched a system that was bogged down by abbreviations, I'd be able to form a stimulus package of my own for the government. If you feel like your name is too long, and should be shortened, do not "fix" it by abbreviating. There are only two times when abbreviation is acceptable. When it's a common abbreviation (such as URL, RAM, email, etc.); or when your code size matters, such as in the case of Javascript. If your reason is the second one, let me introduce you to an automated technique called Minification.
- Ttl. Another abbreviation. Total is unnecessary in this case. Use generic words like "count" and "total" sparingly, if at all. In the majority of cases, they're too generic to add value to their use, and if the rest of your application is written well, the reader will easily be able to infer that meta piece of information.
- 01, 02, 03. One day, the people who append generic numeric suffixes to variable names, will be set on fire and become Ashleys. We could easily fill a book on why this is a bad practice; completely indecipherable intent, accidental confusion with integer constants (especially if one uses a variable name like that in an expression: numBckWLinFtTtl01+01), or difficulty of managing multiple variables that only differ by the number on the end. But most importantly, always program like the next guy who takes over your code may be a serial killer. Keep that in mind the next time you think this it's acceptable to have a dateLastUsed04 in the system.
Now, what about the second set of names? Well, those make more sense in the given system. I don't even have to tell you anything about how the system works, or what it does, for you to start to understand what those three variables do. That's really the point. I want to be able to look at a variable, method, or class name, and immediately understand the purpose and use of the object.
Before you create an object; spend a little bit of extra time and consideration to it's name. If you can't come up with a good name that describes the intent, then perhaps you should re-examine the purpose of your new entity. After all, if you can't explain what it's purpose is, how can you expect someone else to come along after you and figure it out?
