Mnemonic names are names that make it clear what they are for. I’ve always viewed mnemonic names as being an important part or self-documenting code. There is little question that they make reading someone’s code a lot easier. But there is probably a better reason for using them even if you are working on your own code.
There is an awful lot to think about in any program of any size. The more lines of code, the more modules, variables, constants and other pieces of the puzzle there are the harder it is to keep everything in ones mind. Anything that one doesn’t have to waste a lot of cycles thinking about means more cycles available for the harder things. There is no reason to have to guess what something is for if it has a good mnemonic name.
I had a student once who was the victim of other students trying to copy his code. Generally I was able to catch them but he decided that he wanted to cut that sort of thing off early. What he did was to give all of his variables completely meaningless names. No one would copy his code now because the names were too obvious. They couldn’t copy the code and change the names easily because they could never quite figure out what each variable was for. Had they worked hard enough to figure out his code they would have been able to write their own. The latter is of course what did happen – they started working at learning what they were supposed to. As I became more experienced (this was during my first year teaching high school) I was able to spot this sort of thing before it became a problem BTW.
This sort of thing may work for very small programs and very smart people but it is hardly a good practice in the long run. In the long run, giving things good mnemonic names is the real short cut.
This is the tenth of a series of posts based on the book Programming Proverbs by Henry Ledgard. The index for the series is an earlier post and discussion of the list as a whole is taking place in the comments there. Comments on this “proverb” are of course very welcome here.