VBA
Namnkonventioner

Variabla namn

Variabler innehåller data. Namnge dem efter vad de används för, inte efter deras datatyp eller omfattning, med ett substantiv . Om du känner dig tvungen att numrera dina variabler (t.ex. thing1, thing2, thing3 ), kan du överväga att använda en lämplig datastruktur istället (t.ex. en matris, en Collection eller en Dictionary ).

Namn på variabler som representerar en iteratable värdegrund - t.ex. en array, en Collection , en Dictionary eller en Range celler bör vara plural.

Några vanliga VBA-namnkonventioner går så:

För variabler på procedurnivå :

camelCase

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

    Dim procedureVariable As Long
    Dim someOtherVariable As String

End Sub

För variabler på modulnivå:

PascalCase

Public GlobalVariable As Long
Private ModuleVariable As String

För konstanter:

SHOUTY_SNAKE_CASE används vanligtvis för att differentiera konstanter från variabler:

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

Men PascalCase namnen gör renare utseende och är lika bra, med tanke på att IntelliSense använder olika ikoner för variabler och konstanter:

Ungersk notation

Namnge dem efter vad de används för, inte efter deras datatyp eller omfattning.

"Ungersk notation gör det lättare att se vilken typ av variabel som är"

Om du skriver din kod, till exempel procedurer, följer principen om ett enda ansvar (som det ska), bör du aldrig titta på en screenful av variabla deklarationer högst upp i någon procedur; förklara variabler så nära deras första användning som möjligt och deras datatyp kommer alltid att vara synligt om du förklarar dem med en uttrycklig typ. VBE: s Ctrl + i- genväg kan också användas för att visa en variabeltyp i ett verktygstips.

Vad en variabel används för är mycket mer användbar information än dess datatyp, särskilt på ett språk som VBA som glatt och implicit omvandlar en typ till en annan efter behov.

Tänk på iFile och strFile i detta exempel:

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

Jämföra med:

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 passeras ByRef i det översta exemplet, men förutom det faktum att vi har turen att se att det uttryckligen passeras som sådant, finns det inget som tyder på att strData faktiskt returneras av funktionen.

Det nedre exemplet namnger det outContent ; detta out prefix är vad ungersk notation uppfanns för: för att hjälpa till att klargöra vad en variabel används för , i detta fall för att tydligt identifiera den som en "out" -parameter.

Detta är användbart eftersom IntelliSense i sig inte visar ByRef , även om parametern uttryckligen skickas genom referens:

Som leder till...

Ungern gjort rätt

Ungersk notation hade ursprungligen inget med variabla typer att göra . I själva verket är ungerska notationen gjort rätt faktiskt användbar. Tänk på detta lilla exempel ( ByVal och As Integer borttagna för korthet):

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

Jämföra med:

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

src och dst är ungerska notationsprefix här, och de förmedlar användbar information som annars inte kan dras ut från parameternamn eller IntelliSense som visar oss den deklarerade typen.

Naturligtvis finns det ett bättre sätt att förmedla allt genom att använda korrekt abstraktion och riktiga ord som kan uttalas högt och vara vettigt - som ett förfalskat exempel:

Type Coordinate
    RowIndex As Long
    ColumnIndex As Long
End Type

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

Procedurnamn

Förfaranden gör något . Namnge dem efter vad de gör, med ett verb . Om det inte är möjligt att namnge en procedur är det troligt att förfarandet gör för många saker och måste delas upp i mindre, mer specialiserade procedurer.

Några vanliga VBA-namnkonventioner går så:

För alla procedurer:

PascalCase

Public Sub DoThing()

End Sub

Private Function ReturnSomeValue() As [DataType]

End Function

För procedurer för händelseshanterare:

ObjectName_EventName

Public Sub Workbook_Open()

End Sub

Public Sub Button1_Click()

End Sub

Eventhanterare namnges vanligtvis automatiskt av VBE; byta namn på dem utan att döpa om objektet och / eller den hanterade händelsen kommer att bryta koden - koden kommer att köras och kompilera, men hanteringsproceduren kommer att vara föräldralös och kommer aldrig att köras.

Booleska medlemmar

Tänk på en Boolean-återvändande funktion:

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

Jämföra med:

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

Den Can prefix tjänar samma syfte som b prefix: den identifierar funktionens returvärdet som en Boolean . Men Can läser bättre än b :

If CanReadFile(path, content) Then

Jämfört med:

If bReadFile(strFile, strData) Then

Överväg att använda prefix som Can , Is eller Has framför Boolean-returnerade medlemmar (funktioner och egenskaper), men bara när det tillför värde. Detta överensstämmer med gällande Microsoft-riktlinjer för namngivning .