VBA Procedure Names


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:


Public Sub DoThing()

End Sub

Private Function ReturnSomeValue() As [DataType]

End Function

For event handler procedures:


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.