If you’ve worked with Visual Studio for any length of time, you’ve probably noticed an inverse relationship between convenience and performance. Visual Studio is powerful on its own. And it gets a whole lot more powerful once you start adding plugins. But sometime between that clean Visual Studio install and your 20th helpful plugin, a noticeable slowdown occurs. The user experience starts to suffer.
Of course, this isn’t unique to Visual Studio. It applies to pretty much anything with a plugin ecosystem, such as a WordPress website or your browser. In all of these cases, you have to weigh the value of the plugin against the performance hit you suffer. But in the world of Visual Studio plugins, you often have more and better options than just disabling the plugins. You can manage them.
This is true of CodeIt.Right, SubMain’s automated code review tool. With a tool that provides code analysis, you might think your only lever to pull comes from turning warnings on and off. Not so. CodeIt.Right supports the concept of profiles, which let you set up different sets of rules to execute at different times. And this can really help the efficiency of your development efforts.
The Rationale for Profiles
Over the years, I’ve helped a lot of shops adopt the practice of automated unit tests. One of the most critical pieces of advice I give often surprises people initially. I tell them that a fast test suite is absolutely critical. And I’m far from alone in giving this advice.
Now, this may seem obvious in a sense. All things being equal, faster is, of course, better. But I go so far as to argue that your unit test suite becomes extremely ineffective if it takes a while. In fact, a long-running test suite becomes nearly useless. Why? Because it actively discourages people from using it. If your unit test suite takes minutes or even hours to run, how frequently will you really run it?
You hear about this a lot in the context of unit testing — not as much in other situations. But it’s just as important elsewhere. If your automated code review tool takes a long time to run, people will stop running it. This isn’t laziness on their part. Quite the contrary, in fact. They stop running it because it slows them down and prevents them from getting their work done.
So to get the most out of a tool like this, it’s extremely important that you pay close attention to how efficiently you’re using it. The world of automated unit tests has the notion of a “test pyramid,” in which you have quick tests that you run all of the time and longer running ones that you run less frequently. Let’s take a look at different strategies for achieving the same thing with CodeIt.Right. How can you segment your analysis to get the best of both worlds: speed and thoroughness?
Filter by Rule Type
Let’s start with the conceptually easiest way to segment your analysis profiles. CodeIt.Right categorizes code rules by rule type. Here are those types, collapsed in the profile editor window.
So if your codebase is growing and analysis takes longer and longer, you can create a lighter weight profile and deselect some of these categories. For instance, if this isn’t an ASP project or if you’re not using XAML, those are obvious rule types to cut out. Or maybe you don’t think it’s important to run constant checks for globalization and security concerns. You can remove those from the profile you run most commonly and just run them weekly or so.
Segment by Severity
CodeIt.Right’s rules also contain another helpful piece of information: severity. This segments all of the rules into five levels of severity, ranging from informational to critical error.
This provides you with another fairly straightforward segmentation strategy. You can run analysis looking for only the most critical of issues on a routine basis. Then you can use a different, less-frequently-run profile to do a more thorough check. This lets you prioritize detection of the sorts of issues that you don’t want to let linger, but without taking as much of a regular performance hit.
Segment by Individual Developer
So far, we’ve looked at strategies for segmenting based on the properties of the issues themselves. But you can also supply automated code reviews tailored to individual developers themselves.
For instance, if you have newer or less experienced team members, you may want to have them run the full suite of warnings. After all, these folks will necessarily be in something of a learning mode for a while. So you’re typically not as concerned with them producing code in large volumes as much as you want them to pick up good habits, learn the codebase, and grow. You can thus justify having them spend more time running automated analysis than more experienced team members.
Or you can create individualized profiles based on historical issues that the person has had. For instance, if someone has been performing CodeIt.Right automated analysis for years and internalized its rules, they may need only an occasional checkup.
Disable Processing-Intensive Rules
There are a handful of particularly processing-intensive rules. Those include the following:
- (Performance) Remove unused internal classes
- (Performance) Remove unused private methods
- (Performance) Remove unused locals
- (Usage) Do not prefix calls with ‘base’ (‘MyBase’ in Visual Basic) unless local implementation exists
- (Usage) Calls to local members should be prefixed with ‘this.’ (‘Me.’ in Visual Basic)
So it might be worth trying to remove these rules from your most commonly executed profiles and then to see what your performance improvement looks like. If you go this route, though, make sure you’re running a profile that includes these rules at times as well — particularly the ones relating to dead code.
You have another option at your disposal as well, and it’s a lot different from the ones I’ve mentioned so far. You can use attribute-based exclusions in your code itself to help with processing.
As an obvious example, imagine that you’re working with generated code — say something like an ORM or Entity Framework migrations. You don’t want an automated code review tool reviewing this code. With CodeIt.Right’s exclusions, you have a sophisticated and flexible set of options for marking code to be ignored.
Of course, you need not limit yourself to automatically generated code. Perhaps you have a project that’s essentially stable and unchanging. Or maybe you want to turn off errors about async and ASP for a project containing domain objects. You have a lot of flexibility here.
The last option that I’ll mention for balancing performance and thoroughness has to do with your solution. Specifically, you can filter based on properties related to the solution.
This includes a set of temporal options. Analyze anything that you’ve modified today or this week only (or whatever relative date you feel most appropriate). Likewise, you can set a specific date and analyze since that date. Both options let you ignore large swaths of unmodified code in order to give your analysis a boost.
But you have other Visual-Studio-related options as well. You can analyze only files currently open in Visual Studio or that are checked out from source control. And finally, you can use a wildcard-based querying system to analyze only for certain types of files or files with certain name patterns.
Striking the Right Balance
As readers of the CodeIt.Right Rules, Explained series know, I loathe to advise anyone to ignore automated analysis warnings. In an ideal world, you’d have compact enough projects and enough processing power that none of this would be necessary.
But you don’t need me to tell you that we don’t live in an ideal world. And in a less-than-ideal world, if your tools start to bog down your processes, you start using them less and less. An automated code review is far too valuable a process for you to let that happen. You need to use judicious segmenting with your profiles to make sure that you’re routinely running the analyses you deem most important while running others at periodic intervals.
Luckily, the tool authors understand that need and provide you with a great deal of flexibility for prioritization. So make sure you use it as needed to keep your automated reviews quick and maximally impactful.