[Note: this is about static code analysis generally, I haven't programmed under MISRA C] I have certainly seen in my professional life that "modify the code un

[Note: this is about static code analysis generally, I haven't programmed under MISRA C] I have certainly seen in my professional life that "modify the code until the static checker stops showing a diagnostic" is not a good way to obtain stable and reliable code and I want to 100x "all modifications have a non-zero probability of introducing a fault". I think this sort of thing is compounded by a process that leaves this sort of linting as a matter to be done just before release. Let alone (ugh we did this) adding a whole new static checker to a product just before release, asking devs to address the diagnostics as quickly as possible without regard to test coverage (or, indeed, doing anything beyond compile testing in most cases!), to related faults seen in the field, or their familiarity with the particular area of code. Where I've seen the best success is where a single class of diagnostic is identified as relevant based on actual faults; enabled as a warning; addressed by developers who are conversant with that part of the code and where there is coverage; and eventually elevated to an error rather than a warning when zero diagnostics remain. However, even this tends to introduce some new faults that make it past testing.