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.
Consider a Boolean-returning function:
Function bReadFile(ByVal strFile As String, ByRef strData As String) As Boolean End Function
Function CanReadFile(ByVal path As String, ByRef outContent As String) As Boolean End Function
Can prefix does serve the same purpose as the
b prefix: it identifies the function's return value as a
Can reads better than
If CanReadFile(path, content) Then
If bReadFile(strFile, strData) Then
Consider using prefixes such as
Has in front of Boolean-returning members (functions and properties), but only when it adds value. This conforms with the current Microsoft naming guidelines.