Vb6

vbNullString is a special constant that denotes a null string (0), while "" is a literal empty string. For most purposes, the two are equivalent, but vbNullString is faster to assign and process, and takes less memory. vbNullString is therefore preferred, however some non-VB APIs or components may not properly handle null strings, and their use should be tested.

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.

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.

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.

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.

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

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.

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.

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.

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.

`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.

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.

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`

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.

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.

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.

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

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.

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:

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.

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

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

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

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.

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

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.

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

Unresolved directive in <stdin> - include::{noncompliant}[]

Write one statement per line to improve readability.

Unresolved directive in <stdin> - include::{compliant}[]

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.

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.

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.

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:

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.

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.

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

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:

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.

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.

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.