How-to: The Reddick VBA Naming Conventions

Copyright © 1995 Greg Reddick. All Rights Reserved.

  1. Introduction - Variable and Procedure names
  2. Prefixes
  3. Suffixes
  4. Object variables and DAO - variables
  5. Database Explorer objects - Table, Query, Form etc
  6. Object Names

Some of the naming tags, prefixes, and qualifiers in this document are derived from the Leszynski/Reddick naming conventions, Copyright © 1994 Stan Leszynski and Greg Reddick.

The purpose of the Reddick VBA (RVBA) Naming Conventions is to provide a guideline for naming objects in the Microsoft Visual Basic for Applications (VBA) language. Having conventions is valuable in any programming project. When you use them, the name of the object conveys information about the meaning of the object. These conventions provide a way of standardizing what that meaning is across the programming industry.

VBA is implemented to interact with a host application—for example, Microsoft Access, Visual Basic, Microsoft Excel, and Microsoft Project. In contrast to previous versions of these conventions, the RVBA conventions cover all implementations of the VBA language, regardless of the host application. Note that some of the tags described in this article might not necessarily have an implementation within some particular host program. The word object, in the context of this document, refers to simple variables, as well as to objects presented in the interface of the VBA host program.

While I’m the editor of these conventions and in 1992 proposed the original conventions for Microsoft Access, they are the work of many people, including Charles Simonyi, who invented the Hungarian conventions on which these are based; Stan Leszynski, who co-authored several versions of the conventions; and Paul Litwin, for his contributions and for getting the conventions in front of the public. Many others, too numerous to mention, have also contributed to the development of these conventions.

These conventions are intended as a guideline. If you disagree with a particular part, replace it with what you think works better. However, keep in mind who will see those changes and place a comment in the header of a module indicating what changes have been made. The conventions are presented without rationalizations for how they were derived; you can assume that there are good reasons for the choices that have been made. Send me any questions or comments about the conventions (see the addresses at the end of the article). Suggestions for future versions are welcome.

Changes to the conventions

These conventions first appeared in print in the charter issue of Smart Access in February of 1993. A significantly revised version appeared in the August 1993 issue.

Some of the tags in the version of the conventions presented here have changed from previous versions. Consider all previous tags to be grandfathered into the conventions—you don’t need to go back and make changes. For new development work, we leave it up to you to decide whether to use the older tags or the ones suggested here.


Using a naming convention requires a considerable initial effort on your part. It also requires that you conform to rules specified by other parties, which is difficult for many programmers. The payoff comes when either you or another programmer has to revisit your code at a later time. Using the conventions makes your code more readable and maintainable.

Greg Reddick is the President of Gregory Reddick & Associates, a consulting company specializing in software development in Microsoft Access, VB, and C/C++. He worked for four years on the Access development team at Microsoft. He’s a coauthor of the Microsoft Access 95 Developer’s Handbook, published by Sybex.

Copyright © 1995 Greg Reddick. You can freely distribute this document.


Reddick VBA (RVBA) Naming Conventions (pdf)
Oracle Naming convention
Tony Toews’s Table and Field Naming Conventions
Q189220 - Microsoft support for spaces in fieldnames.

Copyright © 1999-2024
Some rights reserved