Method name is not PascalCase
ID |
vbnet.maintainability.naming_method |
Severity |
info |
Remediation Complexity |
trivial |
Remediation Risk |
medium |
Remediation Effort |
low |
Resource |
Naming |
Language |
VB.NET |
Description
Reports a Sub or Function declaration carrying an access modifier whose name does not match PascalCase, that is ^[A-Z][A-Za-z0-9]*$ - names starting in lower case such as sendInvoice or recalculate, names using separators such as get_total, and names with a leading underscore such as _reset. Constructors are not reported, since their name is fixed by the language, and neither are property accessors nor event handlers: a method carrying a Handles clause is skipped whatever its signature - including handlers of custom events, which take domain parameters or none at all - and so is the Handler_Event shape wired with AddHandler (Button1_Click, Page_Load), which is an established VB.NET convention. This is a convention rule and is reported at informational severity.
Rationale
Method names are the vocabulary of an API: every call site reads them, and readers rely on capitalization to tell a member from a local or a parameter without going to look up the declaration. .NET has a single convention for this that every framework and library already follows - PascalCase for methods, camelCase for parameters and locals - so a method named sendInvoice reads at its call sites as though it were a delegate variable being invoked, and get_total reads as generated code, since get_/set_ prefixes are exactly what the compiler emits for property accessors. Mixed conventions in one codebase also break the cheapest form of navigation there is, guessing a name: a developer who knows the framework expects Order.CalculateTotal and has to search to discover it is Order.calculate_total. Public and protected method names cross assembly boundaries and become part of the published surface, so the cost of fixing this only grows - renaming after release breaks every consumer, while renaming at declaration time costs one refactoring.
The following code illustrates the pattern detected by this rule:
Public Class InvoiceService
' BAD: camelCase method name.
' FLAGGED: Method name is not PascalCase
Public Sub sendInvoice(ByVal id As Integer)
Console.WriteLine(id)
End Sub
Remediation
Rename the method to PascalCase - an initial capital letter, each subsequent word capitalized, no underscores or other separators: sendInvoice becomes SendInvoice, get_total becomes GetTotal, recalculate becomes Recalculate and _reset becomes Reset. Start the name with a verb describing what the method does, since that is what distinguishes a method from a property. Treat acronyms as words and capitalize only their first letter when they are three letters or longer, as in ParseXmlDocument rather than ParseXMLDocument, while two-letter acronyms stay fully upper case, as in ToIOStream. Use the rename refactoring in the IDE so that every call site, including AddressOf references and Handles clauses, is updated in the same step; for a member that is already published, keep the old name as a wrapper marked <Obsolete> and delete it in the next major version.