A few notes on the readonly field vs readonly property post...

First, Tom (not Ted) pointed out that I removed his use of [DebuggerStepThrough] on the get accessor. I did it to simplify things, but it is a useful thing to do.

Maurits asked, "What would be the drawback of rearchitecturing C# to make public variables compile to public get-only properties?".

Well, I guess I don't see a lot of advantage in doing that, so I guess the chief drawback I'd see is "insufficient utility versus the added complexity". We did play around with different syntaxes that could be used to write properties without having to write the accessors, but it turned out that they either 1) Didn't cover the important scenarios or 2) were as complex as writing the property. We elected not to do that.

Bertrand Le Roy pointed out that there are some frameworks that work with properties but not with public fields. I find this pretty annoying, but this does mean that if you want to use data binding (for example), you'll have to define the properties.

Bjorn Reppen wrote a whole post on his opinion, which I really won't comment on except to say that I'm a firm believer in YAGNI.

Peter Ritchie wrote, "You appear to be contradicting the (framework desgin) Guidelines by suggesting readonly instance fields are a better choice under certain circumstances".

When .NET first came out, there was some talk about writing some general coding guidelines for C#, but we realized that coding guidelines are very specific to teams and can lead to religious discussions, so we opted not to.

Which meant that the only reference we had was the framework design guidelines, which was unfortunate.

The Framework Design Guidelines are great - if you are building a framework. But most people aren't building frameworks - they're building applications, or their building libraries that their group uses directly. In those cases, I think you have to weigh the benefits and the costs.

I think I could have made it clearer that many frameworks fit into the "update this assembly separately" clause.

Finally, there were a couple comments properties being more flexible. My point was that paying for flexibility that you don't need is the wrong place to put your money.

Comments

• Anonymous
  March 20, 2006
  Yes, very unfortunate that the only "offical" code standards/guidelines don't really apply to "most people".  Especially unfortunate in that it re-enforces methodologies (e.g. "never make an instance field public") that are essentially "religious" blanket statements.  Most of the guidance from Guidelines will be telescoped into projects to which it may not apply.
  
  Eric, will you do us the favour and write/spearhead a new ".NET Design Guidelines" initiative as the old version is largely considered replaced by Framework Design Guidelines.  It's pretty clear that this is Microsoft's position (reinforced by many of the rules in Code Analysis).
  _______
• Anonymous
  March 21, 2006
  The comment has been removed
• Anonymous
  April 17, 2006
  One decision I go through we decided readonly Field vs property is whether I will be perfoming DataBinding on it.  Using the DataSource controls seemed to require a Property and not a field for DataBinding.
• Anonymous
  May 29, 2009
  PingBack from http://paidsurveyshub.info/story.php?title=eric-gunnerson-s-c-compendium-a-few-notes-on-the-readonly-field-vs