Cambridge User Group Launch (Evening of September 18th)

Oh yes!

I know have been a little quiet the past few days, and here is why:

We have just launched the Cambridge Region of NxtGenUG.

We have Mike Ormond doing a talk on Silverlight (full 60 minutes), and One of the Microsoft Researchy Guys (to be confirmed whom), doing a talk on F#, We also have Pizza, and We have Swag (free stuff).

It's going to be an amazing event, so please come along. You do need to register so we can plan for pizza and for the security guy at MS Research.

The group will be held at Microsoft Research in Cambridge (Thanks Guys).

After the launch event we will be holding one session every month, and we have some great sessions in the pipeline

Register Here (registration is free, come along and get free pizza):

Anonymous Types

I am going to be quite short in this article because I think Daniel Moth's article can explain anonymous types better than i can. However to be complete i will give a short explanation.

Anonymous Types as the name suggests allows you to create a strongly typed object without declaring the class in the first place (this does rely strongly on local variable type inference and Object Initalisers).

For example:

var mailingListSubscriber = new {emailAddress="a@a.com", spamMe=true};

The cool thing about the example above is that mailingListSubscriber now has full intellisense within Visual Studio. At first I thought that was pretty amazing but if you think about what is happening behind the scenes it makes sense.

The anonymous type is not a latebound object, it is a strongly typed object which is autogenerated behind the scenes by the C# Compiler (open up ildasm and have a look for yourself). This means in reality there is no difference (to the CLR) between an anonymous type and a normal type.




Anonymous Types are restricted in the fact that they can only be used within the scope of a local method. This isn't a restriction imposed by the CLR (as i said the CLR doesn't care), but by the C# Compiler. This is a good restriction though, otherwise us developers would end up writing some unmaintainable crazy nonsense code. So thank you C# team for protecting us (from ourselves).

Is an autogenerated, local scoped, undeclared class useful? Damn straight it is, it is one of the many key features that makes LINQ work. I doubt you will ever use Anonymous Types outside of LINQ queries but boy are they useful there (You will notice anonymous types when using the select part of a LINQ query). Using Anonymous Types within LINQ allows you to focus on interacting with the data (in a safe and strongly typed manner) and forget about unneccasary object declarations, or worry about runtime issues with untyped objects.

I will no doubt discuss LINQ in more detail in one of my future blog posts.

Again thanks to Daniel Moth at Microsoft for keeping me straight as I voyage around the new features.

Local Variable Type Inference

This is a great little feature which is now available in C# 3.0.

Local Variable Type Inference allows you declare a strong typed variable without specifying the type.

For Example:

var myList = new List<string>{"Hello", "World"};

At first I was a little sceptical about this feature. As any good programmer knows it is better and cleaner to know your types etc. From reading the code its not always obvious what the type of the variable is.

However this is nice in theory but in practise it is absolutely sweet, and saves you verbose local declarations.

There are some key points to note:

• This is NOT equivalent to using a late bound object


• Local Variable Type Inference is equivalent to typing the full declaration yourself (the C# compiler will perform the subsitution for you).


• You must initialise with a value (e.g. var myString = "Hello";) so the compiler can infer the type. You cannot skip initalisation (e.g. var myString;) as this will produce a compiler error.


• You cannot switch types (i.e. initialise with a string, and then assign an integer, you must follow the same rules as fully declared types as they are equivalent)


• You can only use Local Variable Type Inference for a locally declared variable scoped within a method (as the name might suggest

As I say although I initially had reservations about this feature, I find that when you are using enumarable types, or just instatiating an object with a large declaration (dictionaries etc), using the var keyword is more readable than double declarations.

Finally thanks to Daniel Moth for helping me out with my worst subject (whioh is giving things the correct name, Doh!)

Next post will be on Anonymous Types (and what they actually are)

C# As, Is and Cast

One of the lovely problems you always get when dealing with databases is DBNulls popping up and ruining conversions to strings, datetimes etc.

Use of "as" and "is" will sort this out.

If you are casting a reference type use "as":

string bob = dr["bob"] as string;

If using a value type use "is" first

DateTime currentTime = DateTime.MinValue;
if (dr["currentTime"] is DateTime)
{
currentTime = (DateTime)dr["currentTime"];
}


This means that you shouldn't end up with DBNull casting errors.

C# / XML Code Formatter for Blogs

I have attached a link below for the code formatter that i use in on my blog

http://www.manoli.net/csharpformat/

Properties / Fields and the JIT

Following on from my previous posts.

I seem to be spending to much time talking about properties but I feel it is important to get a deep understanding of what is going on.

The final point I wish to get back to is that when discussing Properties Vs Fields, I indicated there is a slight performance hit when using a property rather than a field, since a property is really a method.

Whilst this is true in debug mode, it is not true when released.

The reason for this is that our friend the JIT, will replace all calls to property methods with the actual code.

Therefore in my very humble opinion, there is less and less of a reason to use
fields, rather than properties (especially in a world of automatic properties)

Properties Vs Fields

Having talked about Automatic Properties in my last post, i think its important to enter the old Properties vs Fields argument.

Arguments for making all fields private, and using properties:

1) If you have to promote a field to a property any dependant classes will require a recompile.

2) If you wish to use databinding, you need to use a property.

Arguments for using fields rather than properties

1) Slightly better performance (direct access), rather than access through an accessor method

2) More often than not you don't databind directly to a property (so only promote when required)

3) More often than not when we build and release, we build and release all components (unless you are a component developer_

4) More maintainable code (easier to look at than great big hulking property declarations, (not really an issue in a world of automatic properties)

5) Lazy Coding.


I think my preference is fairly clear (properties and automatic properties are good), but I understand if you want to use fields.

I think in a world of automatic properties, fields will not be used as often. I believe this because most coders are lazy (me included). Since automatic properties are so easy to implement there is less reason not use them (apart from those with strong opinions on using fields).

Automatic Properties (Continued)

Following on from yesterdays post about Automatic Properties.

It has been asked, "How do i access the private field"? Unfortunately you can't (you would need to use the normal property declaration to do that).

The private field is automatically generated by the compiler (which you do not have access to). If you wish to look at the private field declaration use ILDASM.

TODO: ILDASM Screenshot

Since you do not have access to the autogenerated private field, you will always been modifying its data through its accessors rather than directly.

Although has a slight performance hit, this inturn will produce more maintainable code.

Automatic Properties

Automatic Properties is a cool new feature which allows us to define properties with the ease of defining fields.

More often that not, when we expose a property in a class, there is no extra logic within that class, and the property is just a wrapper to a private field. This means we end up with verbose code such as:

public class JobPosting
{
    private string _jobTitle;
    public string JobTitle
    {
        get
        {
            return _jobTitle;
        }
        set
        {
            _jobTitle = value;
        }
    }
}

There is no logic implemented in the property (defined in the example above) and it just acts as a wrapper. Automatic properties allows us to define the same code as above, but in a much prettier fashion.

The following snippet gives an example of the same class as before, but this time in Orcas syntax:

public class JobPosting
{
    public string JobTitle { get;set;}
}

As you can see this, is much more readable and compact.

It is important to note that this new orcas style of implementation is NOT equivalent to a field as the compiler will produce the get, set blocks for you. This means that if you do have to implement some logic within your properties, you can use a full get,set block and any external code that uses your class will not require a recompile as the default public interface hasn't changed.

This superb little feature both reduces typing time, improves readability and makes happy little coders.


Roll on Orcas.