« Music On Demand
Main
Chasing The Moon »

Tech OverloadSubliminal Name Naming

October 09, 2005

I make up names for a living; variable names. That's is what programmers do. Sounds simple doesn't it, well it's not, it is hard work. If you want to store information in a program you have to reserve some memory space and give it a name. Giving meaningful names to memory locations is a full time job. Well, that's my story and I'm sticking to it.

When you first learn how to program in any language you must learn the particular language's rules or variable naming conventions. Things like variables can't start with a number or contain any question marks or other such non-sense. If you think it's hard to remember all the naming rules imagine what it's like creating a language and having to make up those rules.

Usually the rules allow enough freedom to get oneself into trouble. Here is a couple of tips that I have come up with about naming variables that I hope might help you when it come time to name your next variable.

  • Starting a variable name with 'my' only shows that you are a rank beginner; Myinteger and Mystring are not good variable names; My Computer is even worse but that is another story.
  • You can make a variable too descriptive - integertoholdthecountofthenumberofcheckswritten - is not a good variable - you will not be able to type that variable the same way six times in a row. Plus it is a proven fact that programs with long variable names run slower.
  • Do not have two variables with only a token difference in the middle of the name. It's hard to tell 'sumbplan' from 'sumdplan'. This problem will manifest itself when writing budget programs, and you will get blamed for the company's inability to make a profit.
  • Do not use too short a variable either. Resist the temptation to use single characters like i and a. At some point you will have to attempt a mass replace on the source code changing the letter i to j and it will be next to impossible to find all the references to the variable but you will find it in all your comments, turning "Now list the options for items" into "Now ljst the optjon for jtems.
  • Never, ever use a swear work in your code. The minute you do the code will break and put a message like "value for dogpoo exceeds expected container limits". This will show up only when your company President is attempting to demo the software to nuns. Not a good career move.

One of the major problems I have is with variables like taxrate. Taxrate is a good variable in that it usually contains something like the rate of tax to charge. In my case thought I get to typing away at the code and before you know it taxrate has morphed itself into taxrage. Some kind of subliminal message to myself is my thought.

Next week we will discuss the intricacies of writing comments.

Posted by jr at October 9, 2005 06:07 PM | Threads

Comments

Sigh.
I know just what you mean.

I took 3 years of high school French and I still have to use www.freetranslations.com

*sourire*

Posted by: Cowtown Pattie at October 10, 2005 09:04 PM

Recently maintaining some legacy COBOL code, so I can add a few tips.

Do not let outsource coders choose names and/or comment in their native language. Insist on English or your company's national tongue.

Do not use homonyms.

Do not use synonyms.

Do not use "witty" names or puns.

Use symbolic constants correctly. 'VAT_rate' is infinitely preferable to 'sixteen_percent'.

Do not hardcode passwords, let alone call the variable 'Password'.

Do be aware that some languages are case sensitive and OTHERS NOT.

Do not re-use a symbolic constant which has the right value but the wrong name. e.g. Number-of-parents vs. Number-of-legs vs. Number-of-A-bombs-tossed-on-Japan all = 2, but giving a contextually correct symbolic name make things easier/obvious to the maintenance guy (ME). Let the compiler do tzhe mapping onto one storage location.

etc etc.

Stu


Posted by: Stu Savory at October 9, 2005 10:50 PM