VBA programming consists of writing statements and comments. Although comments are not explicitly required, they make it much easier to read the code and figure out what it is intended to do. As you've probably noticed, uncommented code is hard to read and difficult to understand. Comments are especially helpful to someone else who may end up working with your code; of course, if it's been a while since you've worked on a particular project, you'll find that those comments can get you back up to speed quickly.
When working with the VBA Editor in Access, you can add comments by prefacing text with an apostrophe. The default setting is that comments appear in green, so they are quickly recognized when scanning through code. Although you can insert comments at the end of a line of code, they are more commonly used before or after a procedure or function. Comments are ignored during code execution. You can have one or many lines of comments in a procedure, and VBA will ignore them all. Comments don't slow down the execution of your code; so you can use them liberally. At a minimum, your comments should list what the procedure is for and when it was written. Figure 5-2 shows a typical procedure with detailed comments—albeit these comments are primarily for training purposes.
You might be wondering why you need to add comments to code you're writing for your own applications. Well, any time you write code, there's a chance that it will be used for more than one application. It's also possible that someone else will eventually inherit your code. If you choose to take a new job elsewhere, the replacement programmer your company hires might need to make changes to your code. If you haven't added any comments to your code, he'll have a hard time understanding your procedures. If you've ever had to examine another programmer's code and found it without comments, you understand the importance of comments.
Comments help you understand why you might have used a particular piece of code. For example, if you hard coded certain values within your application, you might wonder why you chose to use those particular values. Comments can also provide invaluable notes during development and testing. You can include notes about business rules and when to use one process instead of another. During testing, comments are reminders about a problem created or solved by specific lines of code.
Option Compare Database Option Explicit
■this module demonstrates that by explicitly naming a variable "with both the module and variable name, value of the global ■global variable will be used. mintQuantity would also work.
Public intQuantity As Integer
Public curPrice As Currency_
Private Sub FindTotals() Dim intQuantity As Integer Dim curTotalPrice As Currency
■This sub declares the local variable intQuantity ■but does not give it a value, so the value is 0.
■replace [PurchaseBikeNamedVariable] with the name of the current module curPrice = InputBox("Please enter the bike price.", _
"Enter Bike Price") curTotalPrice = PurchaseBikeNamedVariable.intQuantity * curPrice MsgBox curTotalPrice, vbOKOnly, "Total Price"
Private Sub EnterValues()
■this is storing the value into the global variable. intQuantity = InputBox("Please enter the number of bikes", "you want to buy.", "Total Bikes") End Sub_
Private Sub CalculatePrice()
■This sub runs the two subs listed below. ■Although Enter Values stores a quantity in the ■global Variable, intQuantity, the FindTotals sub will ■use the local variable intQuantity to calculate curTotalPrice Ent e rValue s FindTotals
Was this article helpful?