H!
Mittlerweile kann ich endlich selber vermehrt Dinge in SonarQube ausprobieren und bin manchmal schon überrascht.
Es biete umfassende Dashboards und alles ist super intuitiv, aber Code Smell Hints meiner Meinung nach schon oft irrelevant und es gibt auch viele "false Positives".
Es gibt z.B. den Hint der vorschlägt statt einem try-catch das try-with-ressources zu nutzen, damit eine Ressource auch wirklich geschlossen wird. Nur den try-catch zu nutzen führt aber nur zu Problemen, wenn man vergisst die Resource auch zu schließen.
Klar, das kann schnell passieren und dann ist so ein Hint auch gerechtfertigt, aber es wäre cool, wenn SonarQube auch einbeziehen würde, ob nun die Ressource geschlossen wurde oder nicht. Und je nach Fall einen anderen Hint mit unterschiedlicher 'Severity'.
In Wirklichkeit gibt es aber in beiden Fällen den selben Hint.
Das bedeutet, dass statische Codeanalyse "nur" auf unterster Ebene stattfindet, und zwar dem Quellcode. Und hier noch nicht mal "allumfassend", sondern Zeile für Zeile basierend auf Mustererkennung. Also zum Beispiel wird nicht ein ganzer Block Code betrachtet und analysiert sowie letztlich korrekt verstanden und interpretiert, sondern wirklich nur "stumpf" Zeile für Zeile und es geht "rot" an, wenn eine bestehende Sonar-Regel verletzt ist.
Sehe ich das so richtig?
Den Thread bitte nicht falsch verstehen. Ich finde statische Codeanalyse super und bin ein jetzt schon ein Fan. Jedoch möchte ich auch bewusst die Grenzen und Limitierungen erfassen bzw. verstehen.
Seht ihr in der Praxis noch weitere Limitierungen, Grenzen oder Schwachstellen statischer Codeanalyse?
Lg
Zrebna
Mittlerweile kann ich endlich selber vermehrt Dinge in SonarQube ausprobieren und bin manchmal schon überrascht.
Es biete umfassende Dashboards und alles ist super intuitiv, aber Code Smell Hints meiner Meinung nach schon oft irrelevant und es gibt auch viele "false Positives".
Es gibt z.B. den Hint der vorschlägt statt einem try-catch das try-with-ressources zu nutzen, damit eine Ressource auch wirklich geschlossen wird. Nur den try-catch zu nutzen führt aber nur zu Problemen, wenn man vergisst die Resource auch zu schließen.
Klar, das kann schnell passieren und dann ist so ein Hint auch gerechtfertigt, aber es wäre cool, wenn SonarQube auch einbeziehen würde, ob nun die Ressource geschlossen wurde oder nicht. Und je nach Fall einen anderen Hint mit unterschiedlicher 'Severity'.
In Wirklichkeit gibt es aber in beiden Fällen den selben Hint.
Das bedeutet, dass statische Codeanalyse "nur" auf unterster Ebene stattfindet, und zwar dem Quellcode. Und hier noch nicht mal "allumfassend", sondern Zeile für Zeile basierend auf Mustererkennung. Also zum Beispiel wird nicht ein ganzer Block Code betrachtet und analysiert sowie letztlich korrekt verstanden und interpretiert, sondern wirklich nur "stumpf" Zeile für Zeile und es geht "rot" an, wenn eine bestehende Sonar-Regel verletzt ist.
Sehe ich das so richtig?
Den Thread bitte nicht falsch verstehen. Ich finde statische Codeanalyse super und bin ein jetzt schon ein Fan. Jedoch möchte ich auch bewusst die Grenzen und Limitierungen erfassen bzw. verstehen.
Seht ihr in der Praxis noch weitere Limitierungen, Grenzen oder Schwachstellen statischer Codeanalyse?
Lg
Zrebna