Private field name does not follow the _camelCase convention

ID

vbnet.maintainability.naming_field

Severity

info

Remediation Complexity

trivial

Remediation Risk

low

Remediation Effort

low

Resource

Naming

Language

VB.NET

Description

Reports a Private field whose name does not match ^_?[a-z][A-Za-z0-9]*$, the .NET convention for instance state - an optional leading underscore followed by camelCase. Names reported include PascalCase (Total, Entries), which reads as a property or a type, upper case (CACHE), which reads as a constant, names containing separators (stock_count) and Hungarian-style prefixes (m_Warehouse). Only mutable Private instance state is examined: a field with wider visibility is part of the published surface and takes PascalCase instead, and so do Const and Shared members, which are constants rather than instance state and have their own naming rule. Auto-properties, WithEvents declarations and local variables are not fields and are not reported. This is a convention rule and is reported at informational severity.

Rationale

A field is the one name in a type that can be read or written from anywhere inside it, so telling it apart from a local or a parameter at the point of use is what makes a method body readable: with the convention in place, _total = total is obviously "store the argument in the field" and needs no Me. qualifier to be understood, while Total = total reads as an assignment to a property and hides the fact that state is being mutated directly. The distinction matters most in exactly the places bugs hide - a constructor or setter that assigns a parameter to itself, a method that shadows a field with a same-named local, a refactoring that promotes a local to a field and leaves every reference ambiguous. A PascalCase private field is also a standing invitation to widen its visibility later, because it already looks like a member, which is how internal state ends up published by accident; and once the convention is broken in one type, no name in the codebase can be classified by sight any more, so every reader has to scroll to the declaration.

The following code illustrates the pattern detected by this rule:

Public Class StockLedger

    ' BAD: a private field named as if it were a type or a property.
    ' FLAGGED: Private field name does not follow the _camelCase convention
    Private Total As Integer

    ' BAD: separators are not part of the convention.
    ' FLAGGED: Private field name does not follow the _camelCase convention
    Private stock_count As Integer = 0

    ' BAD: Hungarian-style prefix.
    ' FLAGGED: Private field name does not follow the _camelCase convention
    Private m_Warehouse As String

    ' BAD: upper case is reserved for constants.
    ' FLAGGED: Private field name does not follow the _camelCase convention
    Private CACHE As Object

    ' BAD: an initialized field follows the same convention.
    ' FLAGGED: Private field name does not follow the _camelCase convention
    Private ReadOnly Entries As New List(Of String)()

    ' GOOD: leading underscore plus camelCase.

Remediation

Rename the field to an optional leading underscore followed by camelCase: Total becomes _total, stock_count becomes _stockCount, m_Warehouse becomes _warehouse and CACHE becomes _cache. Pick one of the two accepted forms - _camelCase or bare camelCase - and use it consistently across the project rather than mixing them. If the field is genuinely part of the type’s contract rather than its internals, do not rename it: expose it as a PascalCase property backed by a private field, which also gives you a place to validate assignments. Keep Const and Shared ReadOnly values in PascalCase, since those are constants rather than mutable state. Use the rename refactoring in the IDE so that every reference is updated in the same step.

Configuration

This detector does not need any configuration.

References