Multiple false positive detection of the GCI82 rule: "The variable is never reassigned and can be 'final'"

[jpreisner]

Describe the bug
Several case of false detection for rule "The variable is never reassigned and can be 'final'" (GCI82).

In addition to the issues: #121 and #122

To Reproduce
Analyze this open source project : https://github.com/tonikelope/megabasterd

Expected behavior
As written here and here, I expected the rule to detect all variables eligible to be declared as a constant (with final or static final keywords) because this avoids initializing a variable with the same value each time a method is called.

But this rule, implemented as is today, adds a lot of code smell that I don't find relevant (or I need further explanation to understand their relevance):

• Add the 'final' keyword to a method parameter or constructor
• Add the 'final' keyword to a parameter inside a catch
• Add the 'final' keyword to a variable which is initialized in a method when the value is not reassigned BUT the value is not the same between 2 calls method

👉 I can understand the interest to add the 'final' keyword to declare a better intention, but I don't see how adding the final keyword would make the code more sustainable.

Note

The method parameter case will be handled in #121

Screenshots

• On constructor parameter:

• Inside a catch :

• Initializing a variable in a method from another variable:

• Initialization of a local variable in a method which is an array that will have different contents each time the method is called:

• Initializing a class attribute of a parent class:

Software Versions

• SonarQube Version: Community Build v25.8.0.112029
• Plugin Version: 2.1.1

[Jummartinezro]

I think it raises a false positive on getters/setters :

Consider the following code:

import javax.validation.constraints.Pattern;

@Pattern(regexp = "[0-9]{0}|[0-9]{3}", message = "Required")
private String caisse;

public String getCaisse() {
	return caisse;
}

public void setCaisse(final String pCaisse) {
	this.caisse = pCaisse;
}

Rule is raised although variable can be get/set multiple times.
Maybe I'm missing something ?

[N1c0s]

Hello,
Same issue here, multiple (thousands) "false positives".
Should we disactivate rule GCI82?

[dedece35]

Hi @N1c0s,
yes for now.
But could you give us false potives use cases to investigate deeper, please ?

[DjadjiT]

Les Shreks prennent l'issue