purpose of Java rule squid:S2039 (Member variable visibility should be specified)?

[Nick Radov]

Could someone please explain why Java rule squid:S2039 (Member variable visibility should be specified) exists in the first place? Perhaps I'm missing something but this seems like a terrible rule that would encourage developers to violate object-oriented design best practices. The rule fires on any field or method which lacks an explicit access control modifier (private / protected / public). By default members are visible only within the same package (i.e. package private), and in many cases that is the optimal design. If a developer makes such a member private then that would force her to write duplicate code rather than reusing that member across multiple classes in the package. Or if a developer makes such a member protected or public then it becomes part of the exposed API, thus violating the principles of encapsulation and information hiding.

One could argue that the lack of an explicit "package private" access control modifier represents a design flaw in the Java Language Specification. However even if that is the case it wouldn't be appropriate for static analysis tools to have a rule against something which is explicitly allowed in the JLS.

[Nicolas Peru]

Hi Nick, 

There is a bit of history to this rule, it was inspired from other rule engine. It is indeed debatable and that is why it is deactivated by default. The main intent was mainly to prevent "forgetting" specifying a modifier and letting a field with more visiblity than expected. 

Your arguments are legit, package visibility is allowed by the language and is not an issue per say.  I could argue that relying mainly on this visibility is probably a smell about your design and lack of encapsulation between classes. 

In the end, this is mainly a styling issue (because one could also argue that a protected method on a final class could also do the trick), so if you disagree with the rule, feel free to deactivate it. 

Cheers, 

Le mer. 6 avr. 2016 à 19:37, Nick Radov <nick....@optum.com> a écrit :

Could someone please explain why Java rule squid:S2039 (Member variable visibility should be specified) exists in the first place? Perhaps I'm missing something but this seems like a terrible rule that would encourage developers to violate object-oriented design best practices. The rule fires on any field or method which lacks an explicit access control modifier (private / protected / public). By default members are visible only within the same package (i.e. package private), and in many cases that is the optimal design. If a developer makes such a member private then that would force her to write duplicate code rather than reusing that member across multiple classes in the package. Or if a developer makes such a member protected or public then it becomes part of the exposed API, thus violating the principles of encapsulation and information hiding.

One could argue that the lack of an explicit "package private" access control modifier represents a design flaw in the Java Language Specification. However even if that is the case it wouldn't be appropriate for static analysis tools to have a rule against something which is explicitly allowed in the JLS.

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/fb663636-79d9-42bf-8343-0793880bd7f4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Nicolas PERU | SonarSource

Senior Developer
http://sonarsource.com

https://twitter.com/benzonico