It feels like Scrum has been around forever and everybody knows what it is and has interacted with it in one way or another.

Indeed, there were times when everything around scrum was innovative, valuable and efficient: from planning to sprints and so on.

However, recently the number of negative reviews has been escalating.

To keep it interesting, this time I'd like to tell about our approach to developing and polishing diagnostic rules for PVS-Studio Java. You will learn how we keep existing warnings consistent across releases and why the new ones aren't too weird. I'll also share a bit of inside information on what plans we, the Java team, have for the future, and show you a few interesting (and a few plain) bugs we found using the diagnostics from the upcoming release.

If you use static analyzers, you will have, sooner or later, to address the task of making their integration into existing projects easier, where fixing all warnings on legacy code is unfeasible.

The purpose of this article is not to help with integration but rather to elaborate on the technicalities of the process: the exact implementations of warning suppression mechanisms and pros and cons of each approach.