Naming conventions

Having a consistent naming strategy within an application is often overlooked by inexperienced developers. This simple exercise can save so much time for both the original developer and particularly for a developer that takes over an application at a later date. Anyone who has built even the simplest of databases in Access, will be familiar with the following objects: tables, queries and forms. Naming these objects appropriately can have a big impact on how easy it is to maintain your application Lets say you want to build a “Customers” form. Well you will need a table and possibly even a query for that form. Now you could name the table, the query and the form “Customers” if you wished and that would seem logical. But… What if you set the record source of the form to the stored query? You’ll see the word “Customers” in the form’s properties, but when you or another developer return to that property six months later and see the word ‘Customers’, how will you know what type of object it refers to? A table or a query? Also, it really is no fun pouring through lines of code and seeing the word “Customers” over and over again and not knowing what type of object it refers to. There are many reasons to plan an appropriate naming convention for every object, control and variable in your application, I will cover these in another article. But for now I will show you how I name objects within Access: I give each object a self explanatory prefix i.e. the customers table becomes ‘tblCustomers’, the query becomes ‘qryCustomers’ and the form becomes ‘frmCustomers’. Simple. I hope this basic explanation of the need for naming conventions causes you to pause before starting work on your application and spend a little more time at the planning stage. You could save yourself (and maybe us) a lot of time in the future.