Bill Blogs in C#

Microsoft launched a new public facing site that features all the Micorosoft Regional Directors, and our activities all around the world. See it at http://www.microsoftregionaldirectors.com/

People that know me have heard me talk about what a brilliant community the RDs comprise. Spend a few minutes on the site, and you'll see what I mean: it's worldwide, and many of the names are familiar.

And, spend a few moments on this page: http://www.microsoftregionaldirectors.com/profile.aspx?rd=1209

Yup, that's me.  For the local crowd, the picture was taken here: http://www.ewashtenaw.org/government/departments/parks_recreation/sharonmills/pr_pksharon.html

Sharon Mills is a local county park that's been a winery, a Ford parts factory, and a granery.

BTW, as you browse the site, you'll see many of the RDs in local settings.  It's a great virtual trip around the world.

We held our first Open Spaces event in Ann Arbor on Wednesday.  I think it was a success: We had a great series of discussions with almost 40 people attending.  To a very large extent, that success was due to our major co-sponsors: Microsoft and Adobe.  Microsoft sponsored lunch, and provided three knowledgable participants:  Drew Robbins, our region's Community Developer Evangelist, Josh Holmes, our region's Community Architect Evangelist, and Chris Bernard, a User Experience Evangelist from Chicago.  Adobe sponsored breakfeast, and provided James Ward, a Technical Evangelist for Adobe Flex.

One of the key successes to the event was that our industry, despite its reputation for being loud and rude, is full of professsionals with a great deal of respect for each other.  Listening to Drew and James discuss the more advanced features in WPF/e, AJAX, and Flex was a treat for anyone in the room. It's obvious that there is a lot of mutual respect for the developer offerings being created for our community.

One of the questions we planned on discussing at this event is 'which toolkit should you choose?'  The consensus at the end of the day was that there is no wrongs answer.  Whatever you want to build, you can probably build it on any of the platforms we discussed during the day.  Which means you, as part of your planning process, need to divorce yourself from technology, and put yourself in the users' shoes: What are they trying to do?  What experience do they want?  Drew showed some examples of his WPF based photo store. James showed some examples of an insurance investigation app using Flex, and both showed some great page turning applications.  All those examples show how you can create an application that provides a richer experience for you users. And, richer means easier use, more engaging, more focused on them, not on using a computer.

So what's next?

Dianne and I planned this event (privately) as the first of many, hoping to hold one each quarter. The attendance numbers, and the responses we got from those attendees means we are going to do that.  Look for another event somewhere in the summer. We are going to change a few things: First, the name.  Dianne and I came up with this as tongue-in-cheek title. Obviously, we did not expect anyone to come to blows. (Although Josh is starting to develop a resemblance to Stone Cold Steve Austin).   I think everyone that knew either Dianne or I knew that we intended the title in jest. (Dianne and I almost always work in different technologies. We learn from each other, and it helps both of us.)  But, it might be discouraging others from attending. That's not what we want, and we'll come up with a branding that better represents the events.

Second, we're looking for suggestions on themes.  We've got some ideas, and some feedback from Wednesday, but we're soliciting more opinions.  Drop us a line, and we'll consider it.

Yesterday I discussed auto implemented properties. My focus was that the C# langugae team does a great job to see common idioms and extend the language in ways that make us more productve.

Luke Hoban made a great point about comparing the querying syntax in C# 2.0 and 3.0.  Notice the difference in length, and readability.  In my opinion, the 3.0 syntax is much more concise, and much more readable.  That's two big pluses:  I write less code to create more powerful idioms.  And, far more importantly, I can read the end result in much less time, and with far more understanding of the actual use of the software.

Read the post, start at the bottom, and see how C# 3.0 can improve your understand of code you need to maintain.  I think it will make you much more excited about C# 3.0 and the future of development.

My position on fields vs. Properties is pretty well known (See Item 1 in Effective C#).  However, another group of developers that prefer fields, unless the getter or setter actually do real work.  They feel that always using properties violates YAGNI (You ain't gonna need it).  I suppose there is some truth in that. But my opinion has always been that the cost of binary compatibility is much greater than the cost of just making properties all the time.

Quite frankly, I think the YAGNI camp just believes it's more typing.  Instead of this:

public int MyValue;

They need to type this:

private int myValue;
public int MyValue
{
    get { return myValue; }
    set { myValue = value; }
}

Starting with VS 2005, I think they are all wet anyway. I just type this:

public int myValue;

Then right click, select Refactor:Encapsulate field.

But even so, I'll admit that the 6 lines of code for such a simple feature is a bit heavy.  The C# langauge team agreed.  One of the C# team's greatest strength is that they recognize the most common idioms, and add convenient syntax to support them.  In C# 3.0, I can write automatic properties.  This syntax is very clean:

public int MyValue { get; set; }

That produces the same IL as the six lines above.  Automatic properties are gloriously sweet syntactic sugar around one of the most common idioms we use.

You can make read only automatic properties:

public string Name { get; }

You can also make virtual automatic properties:

public virtual decimal Salary { get; set; }

There's nothing magic about automatic properties.  Just because the base class is implemented using automatic properties, the derived classes can override using automatic properties, or regular old property syntax.

So far though, other posts have only scratched the surface of the functionality provided by auto implemented properties. First, while I've only shown public properties, you can obviously create protected, internal, or protected internal properties.

What's more important is that you can also create properties with different accessors. Just like normal properties, you can limit the access to the setter:

public string Things { get; protected set; }

You can also create a simple auto-implemented property that uses a private setter:

public string ReadThings { get; private set; }

This gives you the possibility of creating a property using a very concise and clear syntax, and still limit any modifications to the backing field to your own class.

So, now who has any reason to argue for fields instead of properties?