My blog reader burped recently, and gave forth a post (and reply) than Rico wrote last September, but since I didn't comment on it then, I'll comment on it now. And, yes, I've written about this in the past...

Basically, this revolves around the question of using properties, or using public fields. And I have a slightly different point to make than Rico is making, his point being that sometimes you need to break these guidelines for performance reasons (which I agree with, but which is not my point).

But first, a bit of history...

Back in the early days of .NET, we (and by "we", I mean "other people") were coming up with the .NET framework library coding guidelines and the CLS as a way of making sure that developers could use assemblies developed in multiple languages without severe cranial performance issues. Meetings were held, discussions ranged far and wide, and the CLS and coding guidelines came into being.

And they were pretty good, though they only covered the public appearance of classes. You could use hungarian in the internals of a class, if you wanted to.

We also discussed whether we would come out with a set of guidelines that talked about how things should be done inside your class. For C#, we decided not to do this, and if any of you have ever spent time talking about where braces belong or whether source code should use spaces or tabs, you understand why we decided not to do this.

But I'm afraid that it unfortunately gave the impression that the library coding guidelines should be the drivers for all code that you write, and I think that's the wrong way to look at things. Others may differ inside MS, but they can write their own blog posts...

On the specific subject of properties, the question can be boiled down to:

If I have a field with no special behavior, should I write a "just in case" property (with trivial get/set), or should I expose a public field?

The reason that the library design guidelines suggest you write a property here is that it is important that libraries be easily versioned. If you put a property in there ahead of time, you can change the property implementation without requiring users to recompile their code.

That, in my book, is generally a "good thing".

Or, to put it another way, I rank the ability to version easily higher than the cost of the extra clutter in the class and increased size of the assembly that comes from the property.

But, if the clients of a class are always compiled together with a class - or at least shipped together - then there is no versioning issue to consider. In that case, I think it's a bad idea to write the "trivial property" - all you've done is complicate your code without any benefit. If the public field you write needs to be a property, then just make the change and recompile.

I've switched over to writing this code, and I have to say that when I have to work with old code with trivial properties, it bothers me.

(Oh, and I also made the same choice as Rico when I had to do some graphical stuff...)