Custom Software
.
 The Access Wizard Newsletter . Tips, Tricks and Traps for Access Users and Developers 
July 2004 
.
. . . . . . . . .
Dear Jim,

"When I use a word," Humpty Dumpty said, "it means just what I choose it to mean, neither more nor less."

"The question is", said Alice "whether you can make words mean so many different things.
- Lewis Carroll Through the Looking glass

In the passage above Humpty Dumpty was using words haphazardly. As a result Alice was confused by what he was trying to say. If Humpty had followed the convention of using standard terms in standard ways, it would have been much easier for Alice to understand him. In a similar way, if you use a naming convention in your database projects, you'll work more efficiently.

In This Issue
.
.
 
  • Tip of the Month
  • Naming Conventions
  • Suggested Naming Convention
  • A Couple of Dos and Don'ts
  • Trap of the Month

     
  • Naming Conventions
    .
    If you use a naming convention then it's much easier for you to easily identify objects and their purposes in your database applications. Consider the following 3 SQL statements:

    Select * from students
    Select * from tblStudents
    Select * from qryStudents

    With the first statement you have to guess where the data is coming from - is it a table or a query? The second and third statements make clear the source, especially if you've adopted and followed a naming convention. It's not hard to remember that tbl stands for a table and qry stands for a query.

    Bring this a step further and consider a form that has as its data source, one of the three statements. If there's a problem with the data you'll know exactly where to look for tblStudents or qryStudents, with plain students you'll have to start searching.

    Although the above example is trivial, consider a complex database with hundreds of tables, queries, forms, and reports. A naming convention will help you identify and find what you're looking for much faster.

    Suggested Naming Convention
    .

    Use prefixes for your naming convention

    One of the first decisions for your naming convention is whether to use prefixes or suffixes. Prefixes are the way to go. By using prefixes for your naming convention, similar objects will group together when you sort them, making it easier to see all the objects of a certain type together.

    Once you've decided on prefixes or suffixes you can "grow your own" convention or use one created by someone else.

    The most widely used naming convention in Access is by Leszynski. You can find a copy of it by googling "Access Naming Convention". I use a modified version which you can get at my website below.

     

    Custom Software Naming Convention

    A Couple of Dos and Don'ts
    .
    Do Use mixed case notation
    tblStudents is easy to read, capitalizing the intial t, or going with all upper or lower case makes it much tougher to figure out.

    Don't use spaces
    As I've mentioned in earlier articles, spaces will cause you problems in the long run. The mixed case notation I recommend will make your objects understandable.

    Some folks like to use underscores for spaces. I'm not a fan of this approach since it becomes tempting to use the title of an object to be descriptive rather than identifying.

    Don't use punctuation
    Avoid it like the plague. Punctuation in your object names will get you into trouble. A dash may be misinterpreted to be a minus, a comma will cause trouble if you need to parse data. An apostrophe can easily cause a quoted string to break at an inappropriate point. Although Access may allow you to do to these things, if you even need to upsize to another database such as SQL Server, your use of a standard naming convention will make it an easier road to travel.

    The one exception to this rule is temporary objects which I discuss in this month's tip.

     

     

    For the Coders out there -- In your modules, prefix all variables with the appropriate designator, e.g., str for string, int for integer. This will make debugging much easier and will jog your memory for the type of variable you need as you reference the object.

    Bottom Line: Settle on a Naming Convention and use it religiously.

     

    Custom Software Naming Convention

    Trap of the Month
    .
    Avoid naming objects (including fields) something that has meaning within Access. For instance, don't name a date field "Date" The trap here is that in certain circumstances Access may interpret your field as a request to return the current date. One good way to determine if a word has meaning to Access is to do a search on it. If you come up with a hit, you'll want to change to something else.


     

    Tip of the Month
    For temporary objects use an underscore "_" as the initial character. If you use this convention you'll get two big benefits:

    1. When you sort objects these items will float to the top of your list so you'll be able to see and group them easily.

    2. Any time you see a table, query, form etc, that starts with an underscore you can feel comfortable deleting it because you know that it's a temporary object.

    .
    .
    .
    .
    . Quick Links...

    Our Services

    Selected Presentations from Jim Connell of Custom Software

    Future Newsletter Suggestions, Questions and Comments

    Past Newsletters

    .
    .
    .


    Join our mailing list!
    .

         email: jim@custom-software.biz
         voice: 978-392-3462
         web: http://www.custom-software.biz

    .
    .
    Custom Software - Westford MA 01886

     
    Forward email

    SafeUnsubscribe(TM)
    This email was sent to jim@custom-software.biz, by Custom Software.
    Update your profile |Instant removal with SafeUnsubscribe | Privacy Policy.
    Powered by
    Constant Contact