Rules

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…

It’s time for another post in the CodeIt.Right Rules Explained series.  If this is the first such post you’ve seen, I’ll explain briefly how it works.  CodeIt.Right is an automated code review tool for .NET, and it has a bunch of rules.  In these posts, 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…

This week, we bring you another post in the CodeIt.Right Rules Explained series.  In case this is new for you, with each post in the series, I take you through three CodeIt.Right rules in detail.  CodeIt.Right is an automated code review tool, making use of static code analysis. As I always do with these posts, I’ll start with two solid 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. And, as I always do, I’ll explain that I don’t phrase…

It’s time for another post in the CodeIt.Right Rules Explained series.  I daresay it’s becoming a pretty predictable post series, with a pretty predictable cadence.  And that’s a good thing!  CodeIt.Right offers automated code review, and this series of blog posts gives you a detailed tour of the what and also the why of the code review rules. As has become custom, I’ll start with two solid 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. Every month, I…

Like any good habit, I’ve settled into a cadence with the CodeIt.Right Rules Explained posts.  They’re coming about once per month or so, and each one offers a deep dive into three of CodeIt.Right’s rules.  As always, I’ll start by citing my two personal rules about static analysis, along with a brief explanation. Never implement a suggested fix without knowing what makes it a fix. Never ignore a suggested fix without understanding what makes it a fix. This isn’t a rhetorical game.  I could condense the statements and say “learn the reasoning behind all suggested fixes.”  But I say it the…

Today, I’ll do another installment of the CodeIt.Right Rules Explained series.  This is post number eight in this series.  As always, I’ll start off by citing my two personal rules about static analysis, along with an explanation. Never implement a suggested fix without knowing what makes it a fix. Never ignore a suggested fix without understanding what makes it a fix. This might seem glib.  After all, I could just as easily say, “Learn the reasoning behind all suggested fixes.”  But I say it the way I do to highlight the decision you face when confronted with static analysis warnings. …