Procedures do something. Name them after what they're doing, using a verb. If accurately naming a procedure is not possible, likely the procedure is doing too many things and needs to be broken down into smaller, more specialized procedures.
Some common VBA naming conventions go thus:
For all Procedures:
PascalCase
Public Sub DoThing()
End Sub
Private Function ReturnSomeValue() As [DataType]
End Function
For event handler procedures:
ObjectName_EventName
Public Sub Workbook_Open()
End Sub
Public Sub Button1_Click()
End Sub
Event handlers are usually automatically named by the VBE; renaming them without renaming the object and/or the handled event will break the code - the code will run and compile, but the handler procedure will be orphaned and will never be executed.
Boolean Members
Consider a Boolean-returning function:
Function bReadFile(ByVal strFile As String, ByRef strData As String) As Boolean
End Function
Compare to:
Function CanReadFile(ByVal path As String, ByRef outContent As String) As Boolean
End Function
The Can
prefix does serve the same purpose as the b
prefix: it identifies the function's return value as a Boolean
. But Can
reads better than b
:
If CanReadFile(path, content) Then
Compared to:
If bReadFile(strFile, strData) Then
Consider using prefixes such as Can
, Is
or Has
in front of Boolean-returning members (functions and properties), but only when it adds value. This conforms with the current Microsoft naming guidelines.