VBA
Konwencje nazewnictwa

Zmienne nazwy

Zmienne przechowują dane. Nazwij je po tym, do czego są używane, a nie po typie danych lub zakresie, używając rzeczownika . Jeśli czujesz się zmuszony do numerowania zmiennych (np. thing1, thing2, thing3 ), zastanów się nad użyciem odpowiedniej struktury danych (np. thing1, thing2, thing3 Collection lub Dictionary ).

Nazwy zmiennych, które reprezentują iterowalny zestaw wartości - np. Tablica, Collection , Dictionary lub Range komórek, powinny być w liczbie mnogiej.

Oto niektóre typowe konwencje nazewnictwa VBA:

W przypadku zmiennych na poziomie procedury :

camelCase

Public Sub ExampleNaming(ByVal inputValue As Long, ByRef inputVariable As Long)

    Dim procedureVariable As Long
    Dim someOtherVariable As String

End Sub

W przypadku zmiennych na poziomie modułu:

PascalCase

Public GlobalVariable As Long
Private ModuleVariable As String

Dla stałych:

SHOUTY_SNAKE_CASE jest powszechnie używany do odróżniania stałych od zmiennych:

Public Const GLOBAL_CONSTANT As String = "Project Version #1.000.000.001"
Private Const MODULE_CONSTANT As String = "Something relevant to this Module"

Public Sub SomeProcedure()

    Const PROCEDURE_CONSTANT As Long = 10

End Sub

Jednak nazwy PascalCase sprawiają, że kod wygląda lepiej i są równie dobre, biorąc pod uwagę, że IntelliSense używa różnych ikon dla zmiennych i stałych:

Notacja węgierska

Nazwij je po tym, do czego są używane, a nie po typie lub zakresie danych .

„Notacja węgierska ułatwia sprawdzenie, jaki jest typ zmiennej”

Jeśli piszesz swój kod, na przykład procedury, są zgodne z Zasadą Pojedynczej Odpowiedzialności (tak jak powinno), nigdy nie powinieneś patrzeć na listę zmiennych deklaracji na górze dowolnej procedury; deklaruj zmienne jak najbliżej ich pierwszego użycia, a ich typ danych zawsze będzie widoczny, jeśli zadeklarujesz je jawnym typem. Skrótu Ctrl + i VBE można również użyć do wyświetlenia typu zmiennej w etykiecie narzędzi.

Zmienna jest wykorzystywana o wiele bardziej użytecznych informacji niż jej typ danych, szczególnie w języku takim jak VBA, który w razie potrzeby z radością i niejawnie konwertuje typ na inny.

Rozważmy iFile i strFile w poniższym przykładzie:

Function bReadFile(ByVal strFile As String, ByRef strData As String) As Boolean
    Dim bRetVal As Boolean
    Dim iFile As Integer

    On Error GoTo CleanFail

    iFile = FreeFile
    Open strFile For Input As #iFile
    Input #iFile, strData

    bRetVal = True

CleanExit:
    Close #iFile
    bReadFile = bRetVal
    Exit Function
CleanFail:
    bRetVal = False
    Resume CleanExit
End Function

Porównać do:

Function CanReadFile(ByVal path As String, ByRef outContent As String) As Boolean
    On Error GoTo CleanFail

    Dim handle As Integer
    handle = FreeFile

    Open path For Input As #handle
    Input #handle, outContent

    Dim result As Boolean
    result = True

CleanExit:
    Close #handle
    CanReadFile = result
    Exit Function
CleanFail:
    result = False
    Resume CleanExit
End Function

strData przepuszcza ByRef w przykładzie górę, ale oprócz tego, że mamy szczęście wystarczy, aby zobaczyć, że jest to wyraźnie przekazane jako takie, nie ma żadnych oznak, że strData faktycznie zwrócone przez funkcję.

Dolny przykład nazywa to outContent ; to out prefiks, co notacja węgierska została wynaleziona przez: pomóc wyjaśnić, co zmienna jest używana do, w tym przypadku jasno określić je jako „out” parametr.

Jest to przydatne, ponieważ sam IntelliSense nie wyświetla ByRef , nawet jeśli parametr jest jawnie przekazywany przez odwołanie:

Który prowadzi do...

Węgierskie zrobione dobrze

Notacja węgierska pierwotnie nie miała nic wspólnego z typami zmiennych . W rzeczywistości poprawna notacja węgierska jest rzeczywiście przydatna. Rozważ ten mały przykład ( ByVal i As Integer usunięte ze względu na zwięzłość):

Public Sub Copy(iX1, iY1, iX2, iY2)
End Sub

Porównać do:

Public Sub Copy(srcColumn, srcRow, dstColumn, dstRow)
End Sub

src i dst są tutaj prefiksami notacji węgierskiej i przekazują przydatne informacje, których inaczej nie można by wywnioskować z nazw parametrów lub IntelliSense pokazujących nam zadeklarowany typ.

Oczywiście istnieje lepszy sposób na przekazanie tego wszystkiego, używając odpowiedniej abstrakcji i prawdziwych słów, które można wypowiedzieć na głos i mieć sens - jako wymyślony przykład:

Type Coordinate
    RowIndex As Long
    ColumnIndex As Long
End Type

Sub Copy(source As Coordinate, destination As Coordinate)
End Sub

Nazwy procedur

Procedury coś robią . Nazwij ich po tym, co robią, używając czasownika . Jeśli dokładne nazewnictwo procedury nie jest możliwe, prawdopodobnie wykonuje ona zbyt wiele czynności i należy ją podzielić na mniejsze, bardziej wyspecjalizowane procedury.

Oto niektóre typowe konwencje nazewnictwa VBA:

Dla wszystkich procedur:

PascalCase

Public Sub DoThing()

End Sub

Private Function ReturnSomeValue() As [DataType]

End Function

W przypadku procedur obsługi zdarzeń:

ObjectName_EventName

Public Sub Workbook_Open()

End Sub

Public Sub Button1_Click()

End Sub

Procedury obsługi zdarzeń są zwykle automatycznie nazywane przez VBE; zmiana nazwy bez zmiany nazwy obiektu i / lub obsługiwanego zdarzenia spowoduje uszkodzenie kodu - kod zostanie uruchomiony i skompilowany, ale procedura obsługi zostanie osierocona i nigdy nie zostanie wykonana.

Członkowie logiczni

Rozważ funkcję zwracającą wartość logiczną:

Function bReadFile(ByVal strFile As String, ByRef strData As String) As Boolean
End Function

Porównać do:

Function CanReadFile(ByVal path As String, ByRef outContent As String) As Boolean
End Function

Can prefiks ma służyć temu samemu celowi co b przedrostek: identyfikuje wartości zwracanej przez funkcję jako Boolean . Ale Can brzmi lepiej niż b :

If CanReadFile(path, content) Then

W porównaniu do:

If bReadFile(strFile, strData) Then

Rozważ użycie przedrostków, takich jak Can , Is lub Has przed elementami zwracającymi wartość logiczną (funkcje i właściwości), ale tylko wtedy, gdy dodaje wartość. Jest to zgodne z aktualnymi wytycznymi Microsoft dotyczącymi nazewnictwa .