Rule to detect Unused Public classes or methods

I don’t see any rule which can detect unused public classes or methods. I understand that this is not easy to detect and when classes are referred outside the scope of source code being scanned, you will end up with lots of false positives.
But having such a rule can at least guide the team and they can decide whether the class/method is really unused or not.
Is this in the roadmap to provide such a rule ?

Hi @ankurja,

Thank you for your suggestion.
Similar rules exist for unused private methods and unused private fields.

We do not intend to create corresponding rules for public methods or classes as it would indeed raise many false positives. We focus on rules which raise as little false positives as possible, otherwise the rules are disabled by users.

If you believe that a public method or class is not used and you develop a library, I would recommend to deprecate it. It will raise warnings on code using the deprecated class or method, these warnings will also be visible in SonarQube.

Cheers,
Nicolas

Hi @Nicolas,

I understand your reasoning. However, I am also interested in such a rule. My use case is as follows:

A project of about 50K lines consists of several dozens of modules and hundreds of packages. Only a handful of packages actually form an API in the sense of “should and can be consumed by other code bases”. Most public classes use this visibility solely in order to be accessible by other packages of the same project. The project itself lives in one Git repository and is built using a single Maven aggregator build. While Java 9 and its module system could be a solution, there are of course projects on Java <= 8, or projects who cannot move to Java modules. All in all, this means that a large portion of unused code is never detected by any tool.

What’s your take on this scenario? I think that a “unused public class/method” rule which can be activated selectively for folders of “public only inside the application” packages would be of great value in such projects (see Bean Validation should be enabled were a similar approach was taken for S5128). Would you perhaps be willing to specify a rule for this and accept an outside PR implementing it?

Also, could this be implemented (easily) within the current SonarJava architecture?

Note that my company uses SonarCloud and could therefore not install a custom rule.

Best regards,
Jens

1 Like

Hi @bannmann,

There is indeed a need to detect unused public classes. I don’t deny it. I am however not convinced that adding such a rule in SonarQube would solve the problem. It seems to me that it would raise either many false positives or many false negatives. For example:

  • False negative: any class having an interface which is used somewhere would be marked as used even if it is not.
  • False Positive: Many frameworks pass class names via configuration files. All those classes would look unused to the analyzer.

What’s more, this rule would not be in the default quality profile as it is not possible to provide a good configuration. Thus it would be used very rarely.

An equivalent rule exist for IntelliJ and looking at users feedback they seemed very confused and many disabled the rule.

I would like to second the feature request. We have implemented the exact rule in a plain Java script to fulfil the check in a closed environment, where all calls to public methods are available to the analysis. I understand, this is somekind of a special case, but if you have this special case, you want this rule. So it would be very helpful to have this rule and maybe opt-in, i.e. by default it is not used but you can enable it if you need it.

1 Like

I would like to third the feature request. I don’t see this as a special case at all. If one has a .sln whose projects call each others’ public methods, and does not use fancy reflection, but no other code has access to the built binaries, then all methods are by definition PRIVATE to the solution. I want to find and remove (or archive) all publicly declared methods that are not called from anywhere else in the solution. CodeLens shows this unequivocally as “0 references,” but we currently don’t have a cheap and easy way to find them. Why not give us the gun, with all the appropriate warnings such as the situations you’ve mentioned, and let those of us skilled enough to avoid shooting ourselves in the foot make good use of it?

@Nicolas - I dont see it as a special case either, the boundary for most built or extended business software (LOB apps, etc) is going to be that of the company.

I would sure like to have all of the programs and assemblies in my organization inspected as a whole for this kind of thing. I would love to have something that can analyze the ripple effects of a change to a module and suggest test cases or areas to test for all affected downstream programs.

I’m working on such a rule in .NET/Roslyn at the moment. The challenge is (and that is what @ Nicolas Harraudeau) is hinting on, is that false positives might be plenty, and therefore a showstopper.

So you need some (relative complex) way to configure the known entry points of your application. That is far from trivial, and I’m still not convinced that I will succeed in doing so. Specially, (as pointed out) because some frameworks (in all languages) have there ways to indirectly trigger code.