In Sonar, we have such a rule to check if the code changes ever invoke/use any deprecated APIs(method, class or interface). It is called " “@Deprecated” code should not be used"
We would like to write a rule, to check the legacy code ever use deprecated APIs. If the legacy does, then the SonarQube give warning message to notify developers. We believe that, combined with the previous existing rule, these two rules will work as a double insurance to the code quality of our project.
My question is:
Is this rule already implemented in Sonar?
If it’s not the case, is it feasible and reasonable to implement such a rule?
This rule is already implemented for many languages, use yoursonarinstance/coding_rules?q=deprecated
to see the rules available in your instance.
For legacy code you will probably use only ‘new’ conditions.
The first scan will bring up all issues but not break the build.
Then you have to configure your quality gate and decide whether the use of deprecated code
in new code should break the build or not.
e.g. your quality gate for legacy projects has no new issues with severity Blocker/Critical/Major
Then you might change the severity of the deprecated rules to INFO to keep track of those findings,
but not break the build.
Thank you a lot for your answer. Maybe I didn’t clarify my question very clearly.
Right now, SonarQube has a rule to check any deprecation use in new change code and we have no problem with this rule.
We actually would like to implement a rule that, when a developer deprecate an API, let’s call it methodA(), this rule can help us detect any part of the current project where this methodA() is invoked.
Is this kind of rule already implemented?
If it’s not, is it feasible and reasonable to create such a rule?
Don’t know if i understand your question.
The analysis scope is defined via new code setting (default = previous_version) and properties, e.g. sonar.sources, sonar.exclusions …
The set of rules that should be used for the analysis is defined in the quality profile, every
scanner (SonarJava …) has one default quality profile and maybe more.
We introduced the Sonar rules to our Java project on 7th Oct.2017, and integrated it into Jenkins to guarantee the code quality with continuous inspection. From this day onwards, any code changes get push to gerrit, the Jenkins job will be triggered, and the changes will be analyzed via the SonarQube. For instance, if the code change call any deprecated API, SonarQube will detect and raise warnings, this feature is already in SonarAnalyzer, which is called " “@Deprecated” code should not be used".
If we deprecate a method, and push this change to gerrit, how does SonarQube analyze if that deprecated method has been used by the existing code base?
That is to say, if we deprecate a method/class/interface, how does SonarQube help us check if any part(method, class,interface) of the current project still use the just deprecated API?
I made some investigation these days, and found that it is not feasible to develop a custom sonar rule to meet such a requirement. SonarQube Java Analyzer parses a given Java code file and produces an equivalent data structure: the Syntax Tree . Each construction of the Java language can be represented with a specific kind of Syntax Tree, and the Syntax tree is on a Class/Interface/Enum level, in other words, it is on a Java file level.
When we need to write such a rule to analyzing the existing code base, we need to scan the whole project and check every method/class/interface to see if they ever use the deprecated API, which is not feasible to implement in SonarQube.
What do you think? Could you please give some suggestion?
I haven’t posted in this thread so I’m not sure why you’re tagging me!
SonarQube, by default, scans the entire codebase everytime. Unless you’re doing something funny with inclusions/exclusions to only analyze changes, you should be good to go by default.
