What is wrong with visible instance fields? Part 2

My previous post about visible instance fields actually got a comment, which is my first ever proper comment, unless you count the ones from my brother. Not only that, it actually got commented on by a member of the FxCop team at Microsoft. Crikey! I think that lifts me up from being a Z-list blogger to what, a Y-list blogger perhaps. Anyhow, the comment was that although moving from a visible field to a property won't break source compatibility it will break binary compatibility, which is a fair point. You can see this if you look at the IL for setting a field value compared to setting a property (via our old friend Reflector). ldloc.0 ldc.i4.1 stfld int32 ConsoleApplication1.Thing::Field ldloc.0 ldc.i4.1 callvirt instance ConsoleApplication1.Thing::set_Property(int32) So in some ways it will also break source compatibility if someone is using you class library from an IL application, if there are such crazy people around. But I think this does highlight a problem with FxCop. It was originally designed to help the .NET Framework team find problems in their code. But the kind of problems they need to worry about are not the same as what most programmers need to worry about. Mostly I don't care about binary compatibility, although I can see there will be companies doing component development who do need to care about it. Yes, I can turn off warnings that aren't of interest, but there are so many warnings in there, it's pretty overwhelming to even know where to begin. Perhaps I'm asking too much, after all FxCop was designed for people writing class libraries, but the fact it now ships with Visual Studio 2005, suggests Microsoft are now thinking application developers should be using it as well. If MS do think this, then I think they need to start thinking about having some different modes of operation in there for different use cases. As an example, it would be great to throw an application (ASP.NET or WinForms) at it and it to tell me which public code never gets called. It doesn't do this now, because it doesn't know who's going to be using the assemblies, but if the assemblies aren't shared with other applications then it should be able to work it out. Now, that would be cool...