Thursday, January 18, 2007

Coding with FxCop

Like my co-worker, Brent, I have recently been in the process of designing an writing components of a prototype for the next version of the project I work on. I haven't been this excited about going to work in quite a while. There's nothing like designing and building something new, rather than testing and fixing bugs, and maintaining legacy code. However, today was the first full day that I had experienced the full onslaught of compiler errors that is FxCop. I felt like I was in university again. For the newbies out there, FxCop is an add-on for your .NET compiler that will check your assemblies for non-conformity and smack them down if they step out of line. It's kind of like the Borg, if the Borg had assimilated an hard-nosed, ruler-smacking elementary school teacher.

I was writing code that I thought was pretty good, but FxCop had other things to say about that. Everything from telling me not to initialize member variables to null (something that was ingrained in me to DO from an early age) for performance reasons, to standards of naming any public members of your classes, to globalization, to security considerations, to suggestions for maintainability, it really has something to say about all aspects of my code. At first, it seemed like it was pointless, like I was never going to get through the nearly-endless stream of errors produced by the tool, but slowly and surely, they dwindled to practically nothing. The only ones that remain (and I've since changed the settings so they only report as warnings) are ones that tell me that nothing is using a certain class or a particular method. Well no shit. We're in the process of building a prototype!

This was one of my favourites...take the following class:

    public class Foo


private Byte[] privateBytes;

public Byte[] Bytes{ get{ return privateBytes; } }

The compiler with FxCop tells me that I shouldn't return arrays because it could impact performance. Instead, I should return a strongly-typed collection...of bytes.


But I'm bashing a little too hard, perhaps. On the whole, it's right on the money. I think I only suppressed two or three instances of errors in all the projects that I worked on. I want to have FxCop fully turned on (does that sound dirty?) during the entire development process. Nothing makes you feel better than when what you've created conforms to just about the strictest standards out there, not just of functionality, but of aesthetics. And because nothing is worse than going back and fixing errors in reams and reams of non-compliant code.

However, it can be difficult when your compiler is nudging you, nay, forcing you to implement more, and MORE just to stop the errors. FxCop is like a ghetto pusher, "Just one more method, man...come on, you can fix those errors. Just one more method." Everyone else left the office around 5:30 or so, but I stuck around until 7:15 because I couldn't stand seeing errors. And I enjoyed it.

I think FxCop and I are going to have a love / hate relationship.

1 comment:

Anonymous said...

Now that is interesting :)