Microsoft Office Tutorials and References
In Depth Information
Chapter 9: Working with VBA Sub Procedures
Naming procedures
Every procedure must have a name. The rules governing procedure names are generally the
same as those for variable names. Ideally, a procedure’s name should describe what its
contained processes do. A good rule is to use a name that includes a verb and a noun (for example,
ProcessDate , PrintReport , Sort_Array , or CheckFilename ). Unless you’re writing a
quick and dirty procedure that you’ll use once and delete, avoid meaningless names such as
DoIt , Update , and Fix .
Some programmers use sentence-like names that describe the procedure (for example,
WriteReportToTextFile and Get_Print_Options_ and_Print_Report ).
Scoping a procedure
In the preceding chapter, I note that a variable’s scope determines the modules and procedures
in which you can use the variable. Similarly, a procedure’s scope determines which other
procedures can call it.
Public procedures
By default, procedures are public — that is, they can be called by other procedures in any module
in the workbook. It’s not necessary to use the Public keyword, but programmers often include
it for clarity. The following two procedures are both public:
Sub First()
‘ ... [code goes here] ...
End Sub
Public Sub Second()
‘ ... [code goes here] ...
End Sub
Private procedures
Private procedures can be called by other procedures in the same module but not by procedures
in other modules.
When a user displays the Macro dialog box, Excel shows only the public procedures.
Therefore, if you have procedures that are designed to be called only by other
procedures in the same module, you should make sure that those procedures are declared as
Private . Doing so prevents the user from running these procedures from the Macro
dialog box.
Search JabSto ::

Custom Search