Googleable Field Names

If you search for Visual Basic on the internet, you will get results for no less than three distinct programming languages:

1. Visual Basic .NET (aka, VB.NET)
2. Visual Basic 6 (aka, VB6 or Classic Visual Basic)
3. Visual Basic for Applications (aka, VBA)

As an Access developer, you are probably acutely aware of this problem.  I can't tell you how many times I've done a search for some VBA feature only to be dumped on a page with information for VB.NET.  

The Problem with Ungoogleable Names

When searching for terms with poor Googleability, such as "vba", the results often have poor signal to noise ratio.

Here are the Google search results for "vba continue for":

And here is the second result for that search string:

Why would Microsoft do this?

There is a perfectly rational reason for this Visual Basic search confusion: marketing.  After all, there is a lot of overlap among the three incarnations of Visual Basic.  The syntax in particular is nearly identical, with VB.Net gaining some additional features such as the aforementioned Continue statement.

Given this similarity, Microsoft had a keen interest in making sure that existing VB developers embraced each new evolution of the programming language.  The resulting technical confusion in the world of web search became the innocent bystander victim.

What Does This Have to do with Field Names?

While you won't be searching Google for the table and field names in your Access applications, you will often find yourself searching the application itself for instances of those field names.  For example, if you need to alter your database schema, you'd better be sure what impact those changes will have on your application.

Let's say you've written an accounting application.  You have five different tables that each have a field named, "Amount."  After several years of ongoing development, you realize that one of those tables needs to be normalized further.  As a result, one of those five "Amount" fields will be split out into a new table.  

That sort of refactoring always starts with identifying where the current field is used in your application.  The task is made unnecessarily harder if you've used a generic name like "Amount" which is likely to appear all over the place.

A better way

Whenever possible, use globally unique field and table names.  Instead of having an "Amount" field on both your Invoice and LineItem tables, name one of them "InvoiceAmt" and the other "LineItemAmt."

And, for goodness sake, avoid using reserved words to name your fields.

Image by 377053 from Pixabay