Understanding Naming Conventions

Topic

New Reply

I was intrigued a few weeks ago with the discussion on naming conventions named after somebody whose name I can’t pronounce.

It suggested that in front of tables you put tbl and qry for query, frm for form and so on. It also suggested that field names have no spaces between words. What I need is a simple explanation of why.

For years I used Access without any problems with naming fields with spaces. Suddenly in Access 2000 labels wouldn’t work if I named a field “name”. This brought about my question for Woody’s which generated a lot of discussion.

However, I find that by not putting spaces between field names, I am forever going aroung putting captions on labels, which is a real pain. Also, I have noticed that Northwind, one of Access’ sample databases, uses the no-spaces rule for fields, but does not name its tables tblXYZ and forms frmXYZ.

So what’s the scoop? Should I absolutely be following the naming convention or is it that important? And if so, why?

Reply | Quote

Replies

Hello John,
Someone, likely Charlotte will explain in detail how and when spaces will cause problems. Certainly Access does occasionally delimit using the space and that fact is enough to make me stay away. Having said that, you_can_use_underscore_for_your_separator_without_problems. Hope that helps some.

Reply | Quote

One of the main reasons for using a naming convention is to make it easier for someone else to read and understand your code. Having tbl in front of all table names makes it much easier for someone who didn’t write the code to look at a small section of it and understand what it is doing. It can also make it easier to automate some large changes. For example, programs that used a naming convention were much easier to find and fix date problems in the recent Y2K problem. Automated tools could search the program source code for references to date variables.

Using naming conventions can also eliminate problems with reserved names. For example, tblName is not likely to cause a problem. But a table named Name could cause a problem if the word Name is a reserved name in the language being used, particularly if a new version of the language changes the word Name from not reserved to reserved.

Spaces in names can cause the name to be ambiguous. If the language can’t tell if the space is a delimiter or just part of a name. In that case, you might get an error, or the language might guess which it is. If it guesses right, your program works. If it guesses wrong, you have a bug that is usually extremely hard to find because the error looks right to you.

Reply | Quote

Naming conventions aren’t just for other people who have to read your code. They make it easier to maintain code you wrote a while back too!

Looking at the database window, it may seem redundant to name a table tblWhatever, since you only see it in the tables collection. However, if you refer to in in code, it makes a lot of difference to know that the object you’re referring to is a table or a report or a form or a query simply because you’ve named it to announce that fact. It saves a lot of programming errors to declare your variables with naming conventions as well, since trying to stuff text into a double will bite you every time. With a naming convention, you can avoid those obvious errors (at least, if you pay attention).

I absolutely hate to have to wade through programs that declared their variables as i or j or D1, D2, D3 because I have to first figure out what data types they represent and then figure out whether they’re being used appropriately. It gets even worse when they reuse variables for different kinds of things and you’re left trying to guess at what D2 represents in this particular part of the routine.

As for Microsoft. They have been wildly inconsistent with respect to naming conventions. They actually have a recommended naming convention for Visual Basic that is only slightly related to the industry standards, but they insist that it IS the standard (NOT!). In Access and the other Office apps, they suggest it’s a good idea, but don’t apply it consistently in either their samples or their wizards. That’s one of the reasons that I’ve been devoted to a naming convention for so long–I got fed up years ago with trying to decipher all the variations on variables and objects that Microsoft introduces.

The spaces in names thing probably arose from the end-user marketing that Microsoft has always done on Access. Access has never really handled spaces in names well, although you may have been able to dodge that bullet more easily in previous versions. It shows up more in code and in queries than anywhere else, and Access 2000 is more code dependent that previous versions, especially if you’re playing with ADPs. You’ve never been able to declare variables with spaces, so that isn’t anything new. You’ve always had to put square brackets around references to object names with spaces in them to avoid a syntax error–that isn’t new to Access 2000 either. I personally would rather type in captions or create my own labels than have to go about putting square brackets around everything in a long SQL statement.

Reply | Quote

John’s point about endlessly editing labels has not been addressed – the ideal of course, would be for Access design views to have a replace facility, so one could name using underscore characters (or whatever), and then replace all these with spaces automatically. Never quite understood why these sort of facilities weren’t available (adding numbers to field labels is another example).

I sincerely hope someone will reply to this telling me how stupid I am and that there’s an easy way to do all this. Any offers?

Mark

Reply | Quote

You can set the caption property of the field when you create it, and that caption will be carried forward into labels, regardless of what you name the field. If you don’t enter a caption, Access substitutes the name of the field in labels.

If you aren’t willing to exert that much effort, then you’ll have to look for search and replace utilities on the web.

Reply | Quote