Maintainable Regular Expressions


I've seen a lot of regular expressions in my career. Some genius, others monstrous, some very subtle and some really blunt. The person who wrote the expression usually did his best to make the expression work and finally succeeded in making his expression pass all the test cases he thought up.

The end-result is usually a one liner that has too many ()'s, {}'s and []'s to be human readable ever again. And that is, lets face it, a huge problem. Because no matter how well it was tested, a time will come a bug is found or that the requirements change. 

Then what?!

Usually the expression is thrown away and written from scratch. Or, the expression is carefully dissected, placed over multiple lines, indented and prettied up, all to see what it was supposed to do.

I've also come across documentation where this nicely prettied up version is placed in a word document and each and every line is documented.

It would be so nice if you could just put that documentation right in the code. Wouldn't it?!

MSOCAF rules


As you might have read previously, I've been trying to incorporate MSOCAF directly in both Visual Studio 2010 and Team Build. The simplest solution would be to code up an msbuild task and put those in a target and reference that target in all project files. I know this, but it has a few shortcomings... (mostly that it doesn't play nice with the Supress option in Visual Studio).

So I've been decompiling re-targetting, recompiling the rules a number of times now, and I've become quite good not only in fixing the issues that come from converting FxCop < 10.0 rules to the latest version, but it's becoming easier to read the rules and actually understand what's going on.

Last week a developer came to me and gave me the bad news that MSOCAF had upgraded and that new rules had been added which aren't yet part of our converted ruleset. So I upgraded my local version of MSOCAF and did my usual 7 step program.


Most Reading