I have, at different times, had various opinions on how to treat static analysis violations.

Using Find Bugs and Sonar Way rules, I initially saw any violation as an insult to my code and would do my best to fix all of them.  I realized, however, that this sometimes led to repetitive safety checks (null pointer) or additional code that I didn’t really want.

It’s better not to have violations, of course, but on the other hand, one doesn’t want to add too many lines of code unnecessarily or use additional libraries to fix issues that aren’t really there.

I now have a more pragmatic view and believe that the all violations should be treated as advisory.  It’s better not to have them, but it’s not always necessary to fix them.

The evolution-of-a-software-engineer joke comes to mind.

When working as a team, I think it is enough to have the following principles:

  • Try to avoid introducing new violations
  • For existing violations, have periodic reviews of the reports together as a team and identify those that should be fixed.





This entry was posted in Development, Uncategorized and tagged , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s