Control flow engine, 200?-2007, RIP

Surprise! (not the good kind)

If you use FxCop or Visual Studio Static Analysis and haven’t yet started playing with Orcas, you may be in for a bit of an unpleasant surprise. While the code analysis team is doing all sorts of interesting things for Orcas, one somewhat less desirable change you probably haven’t heard about yet is removal of the control flow engine and, consequently, the following rules which depend upon it:

The reasons given for removing the engine are basically that it’s slow, buggy, and difficult to maintain. Well, we’ve all had to deal with that sort of problem before, but most of us haven’t have the luxury of removing the nasty, old implementation without providing a replacement. I can certainly understand that the code analysis team might be under pressure to rapidly address performance problems introduced by an engine that slows any use of their product by a factor of 2 or more, but this strikes me as a case of throwing the baby out with the bath water.

The one piece of good news is that there seem to be plans to eventually replace the engine. However, we supposedly won’t be seeing the new implementation until at least the post-Orcas release of Visual Studio, which very likely means waiting two years or more. A couple of things to consider:

1. How big a backlog of violations against the missing control flow rules do you think your team will likely create in two years?


2. Given that the code analysis team apparently considers it acceptable to remove this feature set without providing an immediate replacement, how confident are you in their ability to keep development of the replacement at a high enough priority level that it will actually ship in the post-Orcas release of Visual Studio?

On again, off again…

Let’s assume for the moment that the performance hit caused by the control flow engine really does prevent some folks from using FxCop. Even if it doesn’t, performance improvements are probably pretty high on many folks’ wish lists for FxCop, and it would seem likely that the code analysis team has to put up with a lot of complaining on that front. In addition, there are known bugs in the control flow engine and rules, and those problems may cause both some minor inconvenience as well as false confidence that rules are being applied where they’re not. Are these really sufficient justifications for eliminating the control flow engine entirely in Orcas?

Rather than removing the engine, I would much rather see it become an optional, disabled-by-default component. This scenario would remove the potential performance obstacle for new users while still allowing existing customers to at least keep up the same level of screening that was previously applied. If there is concern on the part of the code analysis team that users aren’t aware of the buggy, partial screening against control flow rules, the feature that allows enabling of the control flow engine could include whatever warnings they deem necessary.

Given that Orcas is already in beta, it seems likely that re-introducing the control flow engine might be too big a change to support. If so, another possibility might be to make it available only in the stand-alone FxCop product. Obviously, this would be a little less convenient for users of Visual Studio Code Analysis. However, it would at least allow such users to make their own performance/convenience/quality trade-off decisions rather than having a potentially unsuitable decision imposed upon them by the complete absence of the engine.

I’ve already submitted a suggestion regarding re-introduction of the control flow engine as an optional component on the Microsoft Connect site. If you’re concerned about the removal of the engine, perhaps it’s time to consider voicing your opinion there as well…