Nick’s Code

Search

XNA MVP

Contact

Donate

Categories

Latest News

Twitter


follow nickgravelyn at http://twitter.com


Nick’s Code © Nick Gravelyn, 2008. All rights reserved.

RSS Feed

Let’s Talk C# Features, Pt 1

Posted in .NET, C#, XNA on May 11, 2008 at 10:48am.
There are 10 comments.

With the new XNA 3.0 CTP we now have the ability to work with XNA Game Studio in Visual Studio 2008. This means that all those fancy new C# 3.0 and .NET 3.5 features are there for our use in Windows games. Some will work on Zune and Xbox 360, but there are runtime features that don’t exist yet in the .NET CompactFramework running on those platforms.

So what features will work for all games? Let’s start there. The big one is new auto-implemented properties. How many times have you made a class like this before:

public class MyClass
{
	float someValue;
	string anotherValue;
	bool somethingElse;

	public float Value
	{
		get { return someValue; }
		set { someValue = value; }
	}

	public string AnotherValue
	{
		get { return anotherValue; }
		set { anotherValue = value; }
	}

	public bool SomethingElse
	{
		get { return somethingElse; }
		set { somethingElse = value; }
	}
}

Pretty long for a class that just holds three values. Well with new auto-implemented properties you no longer have to define all of that. So now your games can have a class that looks like this:

public class MyClass
{
	public float Value { get; set; }
	public string AnotherValue { get; set; }
	public bool SomethingElse { get; set; }
}

Much nicer, huh? :) What the compiler does is make a private field for you and then generate the basic get/set bodies automatically. And since this is just a compiler trick, it works for all platforms right off the bat.

For further reading on auto-implemented properties, check out this MSDN page: http://msdn.microsoft.com/en-us/library/bb384054.aspx (just ignore the first code block there; it has nothing to do with auto-implemented properties). And check back for the next parts where I’ll show some more of the nice new features of C# 3.0 and .NET 3.5.



By Jonas on May 11, 2008 at 11:58 am

Nice… thats pretty cool, no more typing long properties..
Looking forward to seeing some more features.

By Budoray on May 11, 2008 at 7:59 pm

Very nice indeed. Coming from a Java background and using MyEclipseIde for development I thought the auto generate setter/getter feature was the next best thing to auto refactoring. Something I could not figure out how to do with VS 2005.

.NET continues to impress me. It wasn’t that long ago that ‘Microsoft’ developers teased us Java developers as ‘point and click’ coders. All kidding aside, this is a nice language feature and I’m glad it’s available for my aging hands, wrists, and fingers.

By Jim Perry on May 12, 2008 at 5:06 am

My take - if I’m not doing any validation on outside code setting a member there’s no need for me to make it private. I’m probably in the minority here I realize. :)

By Nick on May 12, 2008 at 11:48 pm

@Jim: The way I see it is that I type little extra code over using a public field and it keeps me in that OO bubble everyone always talks about. Not to mention that you can easily add an ‘internal’ or ‘private’ access modifier to the set part and instantly you have a read-only property. Let’s see you do that with just your public field. :)

One thing I want to see is a Visual Studio plugin that will take your auto-implemented property and expand it to a fully implemented property. That would be super useful for those times when you decide you do want to add data validation later on. Maybe I’ll look into how hard that functionality would be to make myself.

By Sir Lantis on May 13, 2008 at 9:46 am

@Nick:

[PreInvoke(ValidateMeMethod)]
public String Test{ get; set; }

public bool ValidateMeMethod(String value) { /* Check for bad words here. */ return true; }

Would be soooo cool - compile-time attributes and aspect-support ;)

By Nick on May 13, 2008 at 9:49 am

Agreed! That would be really cool. Now we just have to convince the C# team to do it. :)

By Jim Perry on May 13, 2008 at 9:56 am

“it keeps me in that OO bubble everyone always talks about.”

Being in that OO bubble is usually meaningless. It’s not like your code automatically becomes worse if you just make the member public. :)

“Not to mention that you can easily add an ‘internal’ or ‘private’ access modifier to the set part and instantly you have a read-only property. Let’s see you do that with just your public field.”

Well, if I’d designed my game properly before I started coding I’d probably have known that it needed to be that way and I wouldn’t have made it public in the first place. :p

By Nick on May 13, 2008 at 10:02 am

“Being in that OO bubble is usually meaningless. It’s not like your code automatically becomes worse if you just make the member public.”

The OO bubble keeps FxCop from complaining to me (and me from having to suppress warnings).

“Well, if I’d designed my game properly before I started coding I’d probably have known that it needed to be that way and I wouldn’t have made it public in the first place. :p”

Well we can’t all be as cool as Jim “Machaira” Perry when designing our code. :)

By Jake Staines on May 13, 2008 at 10:23 am

Bear in mind that fields and properties are different things. If you have a public field, and change it to a public property with a get and set, then any code compiled against your class will break when you distribute your new version because it’s expecting a field instead of a property and it can’t find it - you’ll need to recompile all of that other code as well. So when you’re writing classes other people might ever use, it makes sense to never expose public fields and always use properties, in case you need to add validation or transformation code or whatever.

And since there’s no benefit in a public field compared to a public property with a get and a set, only a minor typing saving, it’s a good habit to get into!

By Matt on May 13, 2008 at 10:31 am

I’d be a lot more impressed with this if it could also automatically handle INotifyPropertyChanged - that would be sweeeeeet!



Post A Comment