Dies scheint ein neues Beispiel für ein falsches Positiv der Regel zu sein. "Bedingt ausgeführte Blöcke sollten erreichbar sein" ( Tintenfisch: S2583 ). Weiß jemand, warum SonarQube behauptet, dass if(this.x == 0) in der folgenden Java-Klasse immer als false ausgewertet wird?
Natürlich kann die Variable x auf 1 gesetzt werden und dann wird decrementX() in genau diese Bedingung kommen:
(ausgeführt auf SonarQube Server 5.6.6 mit SonarJava plugin 4.13.0.11627)
Update : Wie von Absurd-Mind angemerkt, freut sich SonarQube, wenn this.x auf x verkürzt wird. Meiner Meinung nach ist das ein falsch-positives.
Dies ist in der Tat ein False Positive (FP), ausgelöst durch Version 4.13.0.11627 des SonarJava-Plugins.
Nach der Untersuchung wird das FP durch einen Fehler in der Handhabung von unären Operatoren in unserer Symbolic Execution (SE) Engine verursacht. Das folgende Ticket behebt das Problem: SONARJAVA-2460 (erwartete Fixversion: 4.14)
Weitere Informationen über das Auftreten des Problems: Klassenfelder werden beim Zugriff mit this.x oder super.x nicht so behandelt, wie sie sein sollten. Sie werden derzeit schlicht und einfach ignoriert (wird durch das JIRA-Ticket behoben). Es hat als Nebeneffekt, dass die Aktualisierung des Feldes, das mit this.x-- auftritt, nicht von der SE-Engine registriert wird: Der symbolische Wert, der dem Symbol% co_de% zugeordnet ist, wird nicht aktualisiert. Wenn also test x ausgeführt wird, ist das einzige, was die Engine zu diesem Zeitpunkt kennt, die (falsche) Einschränkung x == 0 . In diesem Zustand ist die Bedingung immer falsch. Durch das Beheben des Problems weiß die Engine, dass das x > 0 , das in der Bedingung getestet wurde, nicht mehr das gleiche ist wie das, das für die Überprüfung von x verwendet wurde.