Method has too many parameters (6 or more)
ID |
vbnet.maintainability.max_params |
Severity |
low |
Remediation Complexity |
medium |
Remediation Risk |
low |
Remediation Effort |
medium |
Resource |
Complexity |
Language |
VB.NET |
Description
Reports a Sub or Function declaration whose parameter list holds six or more parameters. The threshold is fixed at six, so a five-parameter procedure is not reported. Constructors are not exempt - a Sub New with six parameters is reported like any other procedure - and the finding is pointed at the last parameter in the list. An Overrides member is not reported: its parameter list is fixed by the base class, so the procedure cannot be split or its arguments grouped without ceasing to be an override.
Rationale
A long parameter list is answered at every call site, and the compiler can only check the types. Where several parameters share a type - a street, a city, a post code and a country all passed as String - any two of them can be swapped and the call still compiles, so the defect appears as wrong data in a report or on an invoice rather than as a build error, and it is invisible in a diff. The length itself is usually a symptom: either the procedure does more than one thing and each caller has to supply arguments for the part it does not care about, or a type is missing and its fields are being carried around one by one. That shape also makes the signature expensive to change, because every added parameter is a breaking change for all existing callers.
The following code illustrates the pattern detected by this rule:
Public Class InvoiceService
' BAD: seven parameters, and several share a type - easy to pass in the wrong order.
' FLAGGED: Method has too many parameters (6 or more)
Public Sub CreateInvoice(ByVal customerId As Integer, ByVal street As String, ByVal city As String, ByVal postCode As String, ByVal country As String, ByVal amount As Decimal, ByVal currency As String)
Console.WriteLine(customerId)
End SubRemediation
Group the parameters that travel together into a class or structure that carries them as one value, so the signature states the concepts rather than the fields - CreateInvoice(customerId As Integer, shipTo As Address, total As Money) in place of seven loose arguments. Where the parameters split cleanly by purpose, split the procedure so each part takes only what it needs, and let the caller compose them. For a procedure that is genuinely configurable, pass a single options object with named, defaulted properties instead of adding further optional parameters - the call site then names each value it sets, which also removes the ordering hazard.