```vb6 Bad theme={null} Text = "" ``` ```vb6 Fix theme={null} Text = vbNullString ```

Declaring a variable without specifying its data type leaves the compiler to assign the type that seems the most appropriate - whether it’s what you need or not. Therefore you should always specify the data type.

```vb6 Bad theme={null} Const MyVar = "459" '... Dim NumberOfEmployees ``` ```vb6 Fix theme={null} Const MyVar as String = "459" '... Dim NumberOfEmployees As Integer ```

Loop invariants are expressions whose values do not change during the execution of a loop. Placing the calculation of an invariant inside a loop is confusing, and inefficient because the resulting value will always be the same, yet it must be re-calculated each time through the loop. Therefore invariants should be calculated and stored before loop execution begins.

```vb6 Bad theme={null} For y = 0 to Height-1 For x = 0 to Width-1 i = y*Width + x ' y*Width is invariant '... Next x Next y ``` ```vb6 Fix theme={null} For y = 0 to Height-1 Dim temp as Integer = y*Width For x = 0 to Width-1 i = temp + x '... Next x Next y ```

The local variables in a Static Sub or Function are preserved between calls (meaning that these variables have the same lifetime as the owning module of their procedure). Static procedures should be avoided because they are difficult to test, and can result in unexpected behavior.

```vb6 Bad theme={null} Private Static Function Foo() As Single Dim val As Single ' val retains its value between invocations val = val + 1 Foo = val End Function ``` ```vb6 Fix theme={null} Private Function Foo() As Single Dim val As Single val = val + 1 Foo = val End Function ```

The difficulty of understanding an expression increases for each of the And, Or and Xor operators it contains.

A single expression’s complexity should not become too high to keep the code readable.

```vb6 Bad theme={null} If ( (condition1 And condition2) Or (condition3 And condition4) Or (condition5 And condition6) ) ... End If ``` ```vb6 Fix theme={null} If ( myFirstCondition() Or mySecondCondition() Or myThirdCondition() ) ... End If ```

Explicitly declaring a function’s return data type makes it easier to use the function correctly.

```vb6 Bad theme={null} Function BinarySearch(. . .) [. . .] End Function ``` ```vb6 Fix theme={null} Function BinarySearch(. . .) As Boolean [. . .] End Function ```

It is not possible to handle errors that arise inside error-handling code. Therefore, the declaration of a new error handler within an error-handling section will lead to unpredictable behavior, since the second error-handling routine is activated only after the first error handler has exited.

```vb6 Bad theme={null} Sub InitializeMatrix(Var1 As Integer, Var2 As Integer, Var3 As Integer, Var4 As Integer) On Error GoTo ErrorHandler '. . . Exit Sub ErrorHandler: On Error GoTo ErrorHandlerLastResort '. . . Resume Next ErrorHandlerLastResort: '. . . Resume Next End Sub ``` ```vb6 Fix theme={null} Sub InitializeMatrix(Var1 As Integer, Var2 As Integer, Var3 As Integer, Var4 As Integer) On Error GoTo ErrorHandler '. . . Exit Sub ErrorHandler: '. . . Resume Next End Sub ```

Because Visual Basic 6 does not automatically unload Form s after a program terminates, it is possible for them to remain in memory. Even after Unload ing, they may stay in memory if references remain. Therefore Form s should be explicitly Unload ed, and their references set to Nothing.

```vb6 Bad theme={null} dim f1 as new form f1.show ... f1.hide ``` ```vb6 Fix theme={null} dim f1 as new form f1.show ... f1.hide Unload f1 Set f1 = Nothing ```

Variables declared without the explicit specification of a data type are Variants. Variants can be inefficient to use because at each interaction they are converted to the appropriate type for that interaction. Variants may be required for COM interactions, but even then their type should be specified explicitly.

```vb6 Bad theme={null} Dim Count Dim Bool ``` ```vb6 Fix theme={null} Dim Count As Integer Dim Bool As Boolean ```

Appending '$' to any identifier forces it to the String data type, but this usage is obsolete and should only appear when differentiating string-specific functions from variant functions, such as Left$() versus Left().

Instead, Strings should be explicitly declared with the String datatype.

```vb6 Bad theme={null} Dim Text$ As String ``` ```vb6 Fix theme={null} Dim Text As String ```

\`Select Case statements are useful when there are many different cases depending on the value of the same expression.

For just one or two cases however, the code will be more readable with If\` statements.

```vb6 Bad theme={null} Select Case number Case 1 To 5 MsgBox("Between 1 and 5, inclusive") Case Else MsgBox("Not between 1 and 5, inclusive") End Select ``` ```vb6 Fix theme={null} If ( number >= 1 And number <= 5 ) then MsgBox("Between 1 and 5, inclusive") Else MsgBox("Not between 1 and 5, inclusive") End If ```

Both the "+" operator and the "&" operator can be used to concatenate strings. However, there is a complicated set of rules around the actual behavior of the "+" operator, and whether you will get a concatenation operation, addition, a compiler error, or a Type mismatch error. On the other hand, the "&" operator can only perform concatenation, and is therefore preferred.

```vb6 Bad theme={null} Dim y As String = "Con" + "caten" + "ation" ``` ```vb6 Fix theme={null} Dim y As String = "Con" & "caten" & "ation" ```

Variant functions are inefficient by nature, and should not be used with strings when string-specific versions, denoted by a \`\$ at the end of the name, are available.

This rule flags instances of these functions:

Left(), Mid(), Right(), Chr(), ChrW(), UCase(), LCase(), LTrim(), RTrim(), Trim(), Space(), String(), Format(), Hex(), Oct(), Str(), Error\`

```vb6 Bad theme={null} TrimString = Trim(TestString) ``` ```vb6 Fix theme={null} TrimString = Trim$(TestString) ```

It is far faster to compare the length of a string to 0 than it is to compare the string itself to empty string. Further, the LenB implementation is faster than the Len implementation, and is therefore preferred.

```vb6 Bad theme={null} If Text = "" Then If Text <> "" Then ``` ```vb6 Fix theme={null} If LenB(Text) = 0 Then If LenB(Text) <> 0 Then ```

GoTo is an unstructured control flow statement. It makes code less readable and maintainable. Structured control flow statements such as If, For, While, or Exit should be used instead.

```vb6 Bad theme={null} Sub gotoStatementDemo() Dim number As Integer = 1 Dim sampleString As String ' Evaluate number and branch to appropriate label. If number = 1 Then GoTo Line1 Else GoTo Line2 Line1: sampleString = "Number equals 1" GoTo LastLine Line2: ' The following statement never gets executed because number = 1. sampleString = "Number equals 2" LastLine: ' Write "Number equals 1" in the Debug window. Debug.WriteLine(sampleString) End Sub ``` ```vb6 Fix theme={null} Sub gotoStatementDemo() Dim number As Integer = 1 Dim sampleString As String ' Evaluate number and branch to appropriate label. If number = 1 Then sampleString = "Number equals 1" Else sampleString = "Number equals 2" End If Debug.WriteLine(sampleString) End Sub ```

Declaring multiple variable on one line is difficult to read and potentially misleading since the As typing only applies to the last variable on the line.

```vb6 Bad theme={null} Public AAA, BBB, CCC As String ' AAA and BBB are variants ``` ```vb6 Fix theme={null} Public AAA as String Public BBB as String Public CCC as String ```

Because the value returned never changes, it is inefficient to call Asc/AscW on a String constant. Use the numeric value instead.

```vb6 Bad theme={null} intCode = Asc("*") ``` ```vb6 Fix theme={null} intCode = 42 ```

The Select statement should be used only to clearly define some new branches in the control flow. As soon as a Case clause contains too many statements this highly decreases the readability of the overall control flow statement. In such case, the content of Case clause should be extracted in a dedicated sub or function.

```vb6 Bad theme={null} Select Case number Case 1 To 5 Debug.WriteLine("Between 1 and 5, inclusive") Case 6, 7, 8 Debug.WriteLine("Between 6 and 8, inclusive") Case 9 To 10 'Noncompliant, too many nested statements doSomething1() doSomething2() doSomething3() ... doSomethingN() Case Else Debug.WriteLine("Not between 1 and 10, inclusive") End Select ``` ```vb6 Fix theme={null} Select Case number Case 1 To 5 Debug.WriteLine("Between 1 and 5, inclusive") Case 6, 7, 8 Debug.WriteLine("Between 6 and 8, inclusive") Case 9 To 10 doSomething1toN() Case Else Debug.WriteLine("Not between 1 and 10, inclusive") End Select ```

It is more efficient to skip the function invocation and use the predefined string constants rather than calling \`Chr$() or ChrW$() for the following numbers:

0 - vbNullChar
8 - vbBack
9 - vbTab
10 - vbLf
11 - vbVerticalTab
12 - vbFormFeed
13 - vbCr
13+10 - vbCrLf | vbNewLine
34 - ""\`

```vb6 Bad theme={null} Dim myChar As Char myChar = Chr$(0) ``` ```vb6 Fix theme={null} Dim myChar As Char myChar = vbNullChar ```

Declaring a parameter without specifying its data type leaves the compiler to assign the type that seems the most appropriate - whether it’s what you need or not. Therefore you should always specify the data type.

```vb6 Bad theme={null} Sub SubComputeArea(Length, TheWidth) [. . .] End Sub ``` ```vb6 Fix theme={null} Sub SubComputeArea(Length As Integer, TheWidth As Integer) [. . .] End Sub ```

Empty statements, i.e. \`:, are usually introduced by mistake, for example because:

It was meant to be replaced by an actual statement, but this was forgotten.
There was a typo which resulted in the colon being doubled, i.e. ::\`.

```vb6 Bad theme={null} Dim i, j As Integer i = 1 :: j=2 ' Noncompliant - double : ``` ```vb6 Fix theme={null} Dim i, j As Integer i = 1 : j=2 ```

Use of the bang (!) operator leads to late binding and results in inefficient code. Use the slightly more verbose dot (.) notation instead.

```vb6 Bad theme={null} MsgBox ObjectWithDefaultProperty!Param ``` ```vb6 Fix theme={null} MsgBox ObjectWithDefaultProperty.DefaultProperty("Param") ```

Return of boolean literal statements wrapped into If-Then-Else ones should be simplified.

```vb6 Bad theme={null} Function MyFunction If condition Then MyFunction = True Else MyFunction = False End If End Function ``` ```vb6 Fix theme={null} Function MyFunction MyFunction = condition End Function ```

The requirement for a final Case Else clause is defensive programming. The clause should either take appropriate action or contain a suitable comment as to why no action is taken. Even when the Select covers all current values of an enum, a Case Else case should still be used because there is no guarantee that the enum won’t be extended.

```vb6 Bad theme={null} Dim number As Integer = 8 Select Case number 'Non-Compliant, what to do when number is not between 1 and 10 ? Case 1 To 5 Debug.WriteLine("Between 1 and 5, inclusive") ' The following is the only Case clause that evaluates to True. Case 6, 7, 8 Debug.WriteLine("Between 6 and 8, inclusive") Case 9 To 10 Debug.WriteLine("Equal to 9 or 10") End Select ``` ```vb6 Fix theme={null} Dim number As Integer = 8 Select Case number Case 1 To 5 Debug.WriteLine("Between 1 and 5, inclusive") ' The following is the only Case clause that evaluates to True. Case 6, 7, 8 Debug.WriteLine("Between 6 and 8, inclusive") Case 9 To 10 Debug.WriteLine("Equal to 9 or 10") Case Else Debug.WriteLine("Greater than 10") End Select ```

The use of Option Base to change the lower bound of an array’s index values results in confusing code.

```vb6 Bad theme={null} Option Explicit Option Base 1 '... Dim MyArray(1 To 3) As Integer For I = 1 To 3 MsgBox MyArray(I) Next I ``` ```vb6 Fix theme={null} Option Explicit '... Dim MyArray(0 To 2) As Integer For I = 0 To 2 MsgBox MyArray(I) Next I ```

Nested \`Select Case structures are difficult to understand because you can easily confuse the cases of an inner Select Case as belonging to an outer statement. Therefore nested Select Case statements should be avoided.

Specifically, you should structure your code to avoid the need for nested Select Case statements, but if you cannot, then consider moving the inner Select Case\` to another function.

```vb6 Bad theme={null} Public Sub Foo(A As Integer, B As Integer) Select Case A Case 0 ' ... Case 1 Select Case B ' Noncompliant; nested Select Case Case 2 ' ... Case 3 ' ... Case 4 ' ... Case Else ' ... End Select Case 2 ' ... Case Else ' ... End Select End Sub ``` ```vb6 Fix theme={null} Public Sub Foo(A As Integer, B As Integer) Select Case A Case 0 ' ... Case 1 HandleB(B) Case 2 ' ... Case Else ' ... End Select End Sub ```

Putting multiple statements on a single line lowers the code readability and makes debugging the code more complex.

Unresolved directive in \ - include::\{noncompliant}\[]

Write one statement per line to improve readability.

Unresolved directive in \ - include::\{compliant}\[]

```vb6 Bad theme={null} sampleString = "Hello World" : MsgBox(sampleString) ' Noncompliant ``` ```vb6 Fix theme={null} sampleString = "Hello World" MsgBox(sampleString) ```

Magic numbers make the code more complex to understand as it requires the reader to have knowledge about the global context to understand the number itself. Their usage may seem obvious when writing the code, but it may not be the case for another developer or later once the context faded away. -1, 0, and 1 are not considered magic numbers.

```vb6 Bad theme={null} Function blnCheckSize(dblParameter As Double) As Boolean If dblParameter > 1024 Then ' Noncompliant, 1024 is a magic number blnCheckSize = True End If End Function ``` ```vb6 Fix theme={null} Function blnCheckSize(dblParameter As Double) As Boolean Dim threshold As Integer = 1024 ' Compliant If dblParameter > threshold Then blnCheckSize = True End If End Function ```

A boolean literal can be represented in two different ways: \{true} or \{false}. They can be combined with logical operators (\{ops}) to produce logical expressions that represent truth values. However, comparing a boolean literal to a variable or expression that evaluates to a boolean value is unnecessary and can make the code harder to read and understand. The more complex a boolean expression is, the harder it will be for developers to understand its meaning and expected behavior, and it will favour the introduction of new bugs.

```vb6 Bad theme={null} If BooleanVariable = True Then ... If BooleanVariable <> True Then ... If BooleanVariable OR False Then ... DoSomething(Not False) ``` ```vb6 Fix theme={null} If BooleanVariable Then ... If Not BooleanVariable Then ... If BooleanVariable Then ... DoSomething(True) ```

Nested code - blocks of code inside blocks of code - is eventually necessary, but increases complexity. This is why keeping the code as flat as possible, by avoiding unnecessary nesting, is considered a good practice.

Merging if statements when possible will decrease the nesting of the code and improve its readability.

```vb6 Bad theme={null} If a And b Then If c And d Then ' Noncompliant doSomething() End If End If ``` ```vb6 Fix theme={null} If a And b And c And d Then ' Compliant doSomething() End If ```

An empty \{operationName} is generally considered bad practice and can lead to confusion, readability, and maintenance issues. Empty \{operationName}s bring no functionality and are misleading to others as they might think the \{operationName} implementation fulfills a specific and identified requirement.

There are several reasons for a \{operationName} not to have a body:

It is an unintentional omission, and should be fixed to prevent an unexpected behavior in production.
It is not yet, or never will be, supported. In this case an exception should be thrown.
The method is an intentionally-blank override. In this case a nested comment should explain the reason for the blank override.

```vb6 Bad theme={null} Sub ShouldNotBeEmpty() ' Noncompliant - method is empty End Sub Sub NotImplementedYet() ' Noncompliant - method is empty End Sub Sub WillNeverBeImplemented() ' Noncompliant - method is empty End Sub Sub EmptyOnPurpose() ' Noncompliant - method is empty End Sub ``` ```vb6 Fix theme={null} Sub ShouldNotBeEmpty() DoSomething() End Sub Sub NotImplementedYet() Err.Raise(1, , "NotImplemented") End Sub Sub WillNeverBeImplemented() Err.Raise(1, , "NotSupported") End Sub Sub EmptyOnPurpose() ' comment explaining why the method is empty End Sub ```

If a private field is declared but not used locally, its limited visibility makes it dead code.

This is either a sign that some logic is missing or that the code should be cleaned.

Cleaning out dead code decreases the size of the maintained codebase, making it easier to understand and preventing bugs from being introduced.

```vb6 Bad theme={null} Private Foo as Integer 'Noncompliant: Foo is unused and should be removed Function Compute(A As Integer) Compute = A * 42 End Function ``` ```vb6 Fix theme={null} ```

This rule verifies that single-line comments are not located at the ends of lines of code. The main idea behind this rule is that in order to be really readable, trailing comments would have to be properly written and formatted (correct alignment, no interference with the visual structure of the code, not too long to be visible) but most often, automatic code formatters would not handle this correctly: the code would end up less readable. Comments are far better placed on the previous empty line of code, where they will always be visible and properly formatted.

```vb6 Bad theme={null} a = b + c ' This is a trailing comment that could be very very long -- Noncompliant d = a + 9 REM This is another trailing comment which could be very very long -- Noncompliant e = a * b ' FIXME -- allowed ``` ```vb6 Fix theme={null} ' This very long comment is better placed before the line of code a = b + c REM This is very long comment which is better placed before the line of code d = a + 9 e = a * b ' FIXME ```

Shared coding conventions allow teams to collaborate efficiently. This rule checks that all function names match a provided regular expression.

```vb6 Bad theme={null} Private Sub doSomething() ... End Sub ``` ```vb6 Fix theme={null} Private Sub DoSomething() ... End Sub ```

Hardcoding IP addresses is security-sensitive. It has led in the past to the following vulnerabilities:

Today’s services have an ever-changing architecture due to their scaling and redundancy needs. It is a mistake to think that a service will always have the same IP address. When it does change, the hardcoded IP will have to be modified too. This will have an impact on the product development, delivery, and deployment:

The developers will have to do a rapid fix every time this happens, instead of having an operation team change a configuration file.
It misleads to use the same address in every environment (dev, sys, qa, prod).

Last but not least it has an effect on application security. Attackers might be able to decompile the code and thereby discover a potentially sensitive address. They can perform a Denial of Service attack on the service, try to get access to the system, or try to spoof the IP address to bypass security checks. Such attacks can always be possible, but in the case of a hardcoded IP address solving the issue will take more time, which will increase an attack’s impact.

```vb6 Bad theme={null} Private Sub cmdConnect_Click() sockMain.RemoteHost = txtHost.Text sockMain.RemotePort = txtPort.Text sockMain.Connect End Sub ``` ```vb6 Fix theme={null} ```

Developers often use TODO tags to mark areas in the code where additional work or improvements are needed but are not implemented immediately. However, these TODO tags sometimes get overlooked or forgotten, leading to incomplete or unfinished code. This rule aims to identify and address unattended TODO tags to ensure a clean and maintainable codebase. This description explores why this is a problem and how it can be fixed to improve the overall code quality.

```vb6 Bad theme={null} Rem TODO Add documentation Sub DoSomething() ' TODO End Sub ``` ```vb6 Fix theme={null} ```

Consistent indentation is a simple and effective way to improve the code’s readability. It reduces the differences that are committed to source control systems, making code reviews easier.

This rule raises an issue when the indentation does not match the configured value. Only the first line of a badly indented section is reported.

```vb6 Bad theme={null} Public Sub OutputObject(oOutput As Object) Set oObject = oOutput If TypeOf oObject Is Form Then oObject.Cls ElseIf TypeOf oObject Is PictureBox Then oObject.Cls ElseIf TypeOf oObject Is ListBox Then oObject.Clear End If End Sub ``` ```vb6 Fix theme={null} Public Sub OutputObject(oOutput As Object) Set oObject = oOutput If TypeOf oObject Is Form Then oObject.Cls ElseIf TypeOf oObject Is PictureBox Then oObject.Cls ElseIf TypeOf oObject Is ListBox Then oObject.Clear End If End Sub ```