It’s time again for another post in the CodeIt.Right Rules Explained series. We’re fifteen posts deep into the series now, as you can see from the title. But if you haven’t seen these posts before, I’ll recap the same information I cover in each intro.
CodeIt.Right is an automated .NET code review tool (both C# and VB), and it has a lot of rules to help you. In the posts in this series, I explain those rules in detail.
In all posts in this series, I start out by listing these rules of thumb for static analysis in the hopes that repetition hammers them home.
- Never implement a suggested fix without knowing what makes it a fix.
- Never ignore a suggested fix without understanding what makes it a fix.
And as always, I’ll explain that I don’t use this phrasing to be cute or because I can’t figure out the logical implication of these statements: “always understand why the tool is suggesting a fix.”
I do this because whenever a static analysis tool confronts you with a warning, you face a choice: address the warning or else ignore it. And, either way, you should act intentionally and for the right reasons. If you’re ignoring it, do so because you think the pros of your warning-triggering code outweigh the cons implied by the warning. Don’t ignore it because you don’t understand and don’t feel like doing it. And on the other side of the coin, don’t change your code simply because some tool tells you to. Always understand why you’re changing your code, or else you’re programming by coincidence.
All that said, let’s look at today’s three rules.