Difference between revisions of "Microsoft Access VBA Naming Conventions"

From database24
Jump to navigation Jump to search
Line 2: Line 2:
 
[[Category:Conventions]]
 
[[Category:Conventions]]
 
== General ==
 
== General ==
* Why?
+
As novice developer you usually define names for constants, variables and methods as they occur;
* Pro?
+
you look at a problem, think of a function, add some parameters and that's it.
* Con?
 
  
== Sources ==
+
After a few years of coding—especially once you are forced to refactor some of your legacy
* [http://en.wikipedia.org/wiki/Hungarian_notation Hungarian notation]
+
coding—you will realize that the code is hard to read; it somehow feels "inconsistent".
* [http://www.xoc.net/standards/rvbanc.asp Reddick VBA Naming Conventions]
+
 
* [http://en.wikipedia.org/wiki/Leszynski_naming_convention Leszynski VBA Naming Conventions]
+
Also during normal development you will notice that you keep stumpling upon the same issues again
 +
and again: you're trying to access variables, which are not accessible, you try to use a variable
 +
for a text value and run in to an error as it has been defined for numbers: the list of little
 +
annoyances which are implied when not sticking to consistent conventions is long—add your
 +
favourite annoyance here.
 +
 
 +
The naming conventions depend on the language you are using, but for VBA it is common conviction
 +
to use either the [http://www.xoc.net/standards/rvbanc.asp Reddick VBA Naming Conventions] or the
 +
[http://en.wikipedia.org/wiki/Leszynski_naming_convention Leszynski VBA Naming Conventions], which
 +
are both versions of the [http://en.wikipedia.org/wiki/Hungarian_notation Hungarian notation].
 +
 
 +
The main idea is to prefix everything with a mnemonic for its type.
 +
 
 +
 
 +
 
 +
 
 +
== Code ==
 +
*
  
 
== Summary ==
 
== Summary ==
 
* …
 
* …

Revision as of 12:45, 1 April 2011

General

As novice developer you usually define names for constants, variables and methods as they occur; you look at a problem, think of a function, add some parameters and that's it.

After a few years of coding—especially once you are forced to refactor some of your legacy coding—you will realize that the code is hard to read; it somehow feels "inconsistent".

Also during normal development you will notice that you keep stumpling upon the same issues again and again: you're trying to access variables, which are not accessible, you try to use a variable for a text value and run in to an error as it has been defined for numbers: the list of little annoyances which are implied when not sticking to consistent conventions is long—add your favourite annoyance here.

The naming conventions depend on the language you are using, but for VBA it is common conviction to use either the Reddick VBA Naming Conventions or the Leszynski VBA Naming Conventions, which are both versions of the Hungarian notation.

The main idea is to prefix everything with a mnemonic for its type.



Code

Summary