CodeIt.Right Rules Explained, Part 17
It’s time for a deep dive into yet another three CodeIt.Right rules.? In case you’ve missed it, this continues a post series in which we, well, do a deep dive into the CodeIt.Right Rules.
CodeIt.Right?is an automated code review tool, making it fall under the broad heading of static analyzers.? It checks your source code against a set of rules, both ones that you customize?and a set that comes out of the box.? In this series, we’re focusing on the latter, since those are the ones that will obviously apply to everyone.
Followers of this series will know that I always kick the posts off by listing two static analysis rules of thumb that I advertise as good ideas.
- Never implement a suggested fix without knowing what makes it a fix.
- Never ignore a suggested fix without understanding what makes it a fix.
If this seems a little obtuse, it’s probably because you could condense these two rules into a single one by logical implication: “always understand a suggested fix.”
But I deliberately choose not to phrase it this way, opting for the two separate rules.? I do this to emphasize your choice: ignore the warning or implement a fix.? If you decide to ignore the warning, you should do so only when you’re fully aware of the risks of doing so.? If, on the other hand, you decide to fix the warning, you should always understand what you’re doing when you change your own code.? Otherwise, you’re programming by coincidence.
Don’t program by coincidence.? Instead, take a look at today’s three rules.