Proper Access Code Layout

When people start creating VBA code, they usually chop and cut lines, add bits until it works, then walk away. Another person has no idea how it works. If fact, after a week, the original developer has no idea. Changes get made and code that is no longer required or used remains to muddy the water. There is a proper way to document code so that it is easier to follow and maintain.

The following is an example of thoroughly documented code. It is an extract from a program we produced for a client. You do not have to be a VBA expert, but you can see by the layout and the comments in green, that a Microsoft Access Developer can read through the code and see each step with an explanation. The benefit is that code is easier to modify and debug. This is true not only for other people who may work on it, but also for the original MS Access developer who may not have looked at the code for months or even years.

There are various naming conventions but one common one is the Leszynski naming convention. A few of the main abbreviations are below. For a full list go to¬†As an example, imagine you are looking at some code that has “Customers” in the code. Is it a table or a query? If you use tblCustomers, or qryCustomers, it makes it easier to understand.

Abbreviation Type
tbl Table
qry Query
rpt Report
frm Form
fun Function
sub Subroutine
bas Module (although some use mod)