Local variable name contains an underscore
ID |
vbnet.maintainability.naming_identifier_style |
Severity |
info |
Remediation Complexity |
trivial |
Remediation Risk |
low |
Remediation Effort |
low |
Resource |
Naming |
Language |
VB.NET |
Description
Reports a local variable declared inside a method, function or property accessor whose name contains an underscore - tax_amount, running_total, line_1. The .NET convention for locals is camelCase, which carries word boundaries with capitalization rather than with a separator, so digits inside a name are fine (line1) but a separator before them is not (line_1). Only locals are examined here; fields, constants, methods and type names have their own naming rules, so a declaration is reported by one of them or by this one and never by both. A leading underscore is likewise not reported, since that form is reserved for private fields. This is a convention rule and is reported at informational severity.
Rationale
Underscore-separated locals are the visible trace of a codebase written to more than one convention, usually because code was carried over from C, Python or SQL, and the cost is not the style itself but the loss of the distinction the .NET conventions are built on: PascalCase means a member, camelCase means a local or parameter, and a leading underscore means a private field. Once tax_amount and _taxRate and TaxRate all appear in the same method, a reader can no longer tell from a name whether an assignment touches local state, instance state or a property with a setter behind it, which is exactly the question that matters when reading unfamiliar code for a bug. Underscores also collide with the one place the character does carry meaning in .NET - the leading underscore of a private field - so tax_amount reads at a glance as though it might be a field, and mechanical searching gets harder because a name can no longer be predicted from the words it is made of. Locals are the cheapest names in a codebase to fix, since they never leave the method that declares them.
The following code illustrates the pattern detected by this rule:
Public Function Total(ByVal net As Decimal) As Decimal
' BAD: separators are not part of the camelCase convention for locals.
' FLAGGED: Local variable name contains an underscore
Dim tax_amount As Decimal = net * _taxRate
' FLAGGED: Local variable name contains an underscore
Dim running_total As Decimal
' FLAGGED: Local variable name contains an underscore
Dim line_1 As Decimal = 0D
running_total = net + tax_amount + line_1
Return running_total
End Function
Remediation
Rename the local to camelCase - a lower-case first letter, each following word capitalized, no separators: tax_amount becomes taxAmount, running_total becomes runningTotal and line_1 becomes line1. Keep the leading underscore reserved for private fields so the two remain distinguishable, and use PascalCase only for members. The change is confined to the declaring method, so it is safe to do in one step with the IDE rename refactoring; if the method holds a long run of such names it is usually a sign the code was translated from another language, and it is worth renaming the whole method body at once rather than one name at a time.