Why is this an issue?

Methods with a long parameter list are difficult to use, as maintainers must figure out the role of each parameter and keep track of their position.

void setCoordinates(int x1, int y1, int z1, int x2, int y2, int z2) { // Noncompliant
    // ...
}

The solution can be to:

• Split the method into smaller ones

// Each function does a part of what the original setCoordinates function was doing, so confusion risks are lower
void setOrigin(int x, int y, int z) {
   // ...
}

void setSize(int width, int height, int depth) {
   // ...
}

• Find a better data structure for the parameters that group data in a way that makes sense for the specific application domain

class Point // In geometry, Point is a logical structure to group data
{
    public int x;
    public int y;
    public int z;
 };

void setCoordinates(Point p1, Point p2) {
    // ...
}

This rule raises an issue when a method has more parameters than the provided threshold.

Exceptions

Methods annotated with :

• Spring’s @RequestMapping (and related shortcut annotations, like @GetRequest)
• JAX-RS API annotations (like @javax.ws.rs.GET)
• Bean constructor injection with @org.springframework.beans.factory.annotation.Autowired
• CDI constructor injection with @javax.inject.Inject
• @com.fasterxml.jackson.annotation.JsonCreator
• Micronaut’s annotations (like @io.micronaut.http.annotation.Get)

may have a lot of parameters, encapsulation being possible. Therefore the rule ignores such methods.

Also, if a class annotated as a Spring component (like @org.springframework.stereotype.Component) has a single constructor, that constructor will be considered @Autowired and ignored by the rule.