Poll: Should you identify an Access object (native) with a prefix?

A poll question for readers of the Microsoft Office Blog: Should you identify an Access object (native) with a prefix?

Most anyone who does any kind of custom design or development work in any of the Office applications knows the importance of naming conventions. There's always a bit of controversy about which convention is the best, but in my opinion, there's no best convention. Just adopt one and use it consistently is my advice.

Most conventions used with Office employ a prefix to identify the object or variable, such as strFirstName, intSalary, and so on. You'll see these prefixes in VBA code. However, I often seen the same prefix convention used to name native Access objects--tables, queries, forms, and reports. For instance, a table that contains employee information would be tblEmployees.  A data entry form might be named frmNewEmployees. Other developers stick with the natural naming method when naming Access objects. In this case, the same table and form might be named Employees and New Employees (no prefix). Do the prefixes add anything? Access segregates objects by type, so adding a prefix to identify objects seems a bit redundant, to some developers.

Here's the question—should you identify an Access object (native) with a prefix? Some developers do while other developers use the natural naming convention.

TechRepublic's Microsoft Office Suite newsletter, delivered every Wednesday, is designed to help your users get the most from Word, Excel, and Access. Automatically sign up today!