The English Language Naming Convention
The more time you spend on picking good names, the less time you will spend writing, debugging, testing, and maintaining your software.
The solution domain should model the problem domain. This is a critical concept in software design, and it is an essential concept in naming objects. What does it mean?
It means that you should use the same name to refer to an object that your customer uses. It's that simple.
If your customer calls an object a "turn signal" or a "pay rate", who do you think you are that you should call it something else? How's does that add to the communication load? Does it help the customer? Does it help the person who will have to maintain your code? Does it even help you? Of course not. Coming up with new names for these objects simply creates extra work and confuses all involved.
Make the selection of good names a top priority, but do not go through the process in haste. You should be satisfied with the names in your design before you start coding.
One of the primary benefits of highly readable names is their ability to clarify the purpose, logic, and information flow within your code. Thus, you get the greatest leverage from good names adopted during the design stage. In addition, you enjoy the benefits of well-chosen names in coding, testing, debugging, and perhaps most importantly, maintenance.
Yes, I know underscores are a real pain to type, but they do make the code considerably easier to read. As a fringe benefit, object names with underscores are automatically differentiated from Microsoft's object names and identifiers.
If the name of an object ever fails to convey its purpose, it should be changed immediately if possible and feasible. Every delay will add both to the cost of the change and to the cost of the bad name.
Some people will tell you that the names of objects should never be changed. After all, you're just making more work for yourself. This process is always a pain in the butt, and sometimes it just can't be justified.
If the object is global, you must track down each mention of the object throughout the entire project. In a large program with many programmers, it may actually be prohibitively expensive to change the name of a global variable.
All this being said, you should still make every effort to identify and eliminate inadequate or misleading object names. Miscommunication on any level can kill a project.
Cryptonyms are identifiers that need to be encoded and deciphered. Acronyms are perhaps the most pervasive cryptnoyms that we encounter in daily life, and they bring enough confusion. Anyone who has ever worked for a large corporation or the federal government can testify to this.
Using the cryptonyms that the customer uses is dangerous enough. Bringing in additional cryptonyms of your own or adding any of these terms that dot the software landscape will only add to confusion.
The same can be said for most abbreviations. Almost everyone knows what IBM and NASA stand for, but does DOT stand for the Department of the Treasury or the Department of Transportation?