CodeIt.Right Rules Explained, Part 14
Today, I’m doing another post in the?CodeIt.Right Rules Explained series.? For anyone who hasn’t seen one of these before, here’s briefly how it works.? CodeIt.Right is an automated .NET code review tool, and it has a lot of rules to help you.? In the posts in this series, I explain those rules in detail.
Whenever I post in this series, I start with my two rules of thumb for static analysis.
- Never implement a suggested fix without knowing what makes it a fix.
- Never ignore a suggested fix without understanding what makes it a fix.
As always, I’ll explain that I don’t phrase it this way because I think I’m clever.? I could just say, “Figure out why the tool is suggesting this.”? But I specifically opt not to.
The reason I do this is that whenever the tool confronts you with a warning, you have a choice: address the warning or ignore it.? And in either case, you should make your choice for the right reasons.? Are you ignoring it because you’ve determined that the pros of having it outweigh the cons the tool is warning you about?? Or are you ignoring it because you don’t feel like dealing with it?? The same thing also applies on the side of implementing fixes.
So, that said, let’s look at today’s three rules.