Today, we bring you another post in the CodeIt.Right Rules Explained series.? Up until this point, I’ve been chronicling these posts by their number in the series, but I realize that the numbering: is both academic and relatively easily inferred via the posting category.? Nevertheless, in spite of changing the approach to the title, I’ll recap the premise, as I always do.
CodeIt.Right?is an automated .NET code review tool.? That means that it automatically analyzes your code and applies rules to it.? 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 makes the point.
- Never implement a suggested fix without knowing what makes it a fix.
- Never ignore a suggested fix without understanding what makes it a fix.
I’ll also explain, as I always do, that I don’t use this phrasing to seem clever or because I can’t figure out the more succinct logical conclusion that these two statements imply: that you should always understand why the tool is suggesting a fix.
I do this because static analyzer warnings present you with a choice: address the warning or ignore it.? And, whichever path you choose, you should do so deliberately and for the right reasons.? Decide to ignore the warning because you think what you’re doing isn’t actually a problem.? Or decide to address the warning because you understand that what you’re doing is problematic and not because you’re programming by coincidence.? Always know what you’re doing.
And with that, let’s dive into today’s rules.