Tuesday, July 27, 2010

C# Readability Tips

Just a couple of C# tips I came across that might improve code readability – these are minor style tips really, nothing too earth-shattering.

Tip 1

For events, in C# before calling the delegate you need to check if anyone is listening to avoid a NullReferenceException, which gets ugly the more events you have (like in an MVP pattern).

if (this.DownloadCompleted != null)
{
this.DownloadStarted(this, e);
}


Instead, declare it with an empty anonymous method as a handler like so…

public event EventHandler DownloadStarted = delegate { };


You no longer need to check if anyone is listening every time you fire the event. (However, your code will call the empty method everytime regardless of whether or not an event is subscribed to.)
this.DownloadStarted(this, e);


However you do need to change how you now check for listeners as you can no longer check for != null as there will always be 1 listener – the anonymous method.

if (this.DownloadCompleted.GetInvocationList().Length == 1)
{
// no one listens to me.
}


Tip 2

You do not need to explicitly declare a new EventHandler () when subscribing to an event

this.applicationUpdaterManager.DownloadStarted +=new DownloadStartedEventHandler(Updater_OnDownloadStarted);


Instead, you can write the following

this.applicationUpdaterManager.DownloadStarted += this.Updater_OnDownloadStarted;


Note: you will still get a compile-time warning if you attempt to wire up a method with a different signature

Thursday, July 22, 2010

Serializing Generic Types

There is no way currently of constraining a Generic type to ensure it is serializable at compile-time. However, there is a quick and easy way to check.


if (!typeof(T).IsSerializable)
{
throw new ArgumentException("type is not serializable");
}

Wednesday, July 21, 2010

You Gotta Constrain to Expand...

When you create a Generic class and constrain the Type parameter T, you are actually increasing the number of operations available. I know it sounds like a contradiction but it makes sense when you think about it. By constraining my Type parameter with an Interface for example, I get access to all the operations that Interface defines. If you do not apply a constraint then you are limiting yourself to operations on System.Object!

Quick example...



public interface IPerson
{
int Age { get; set; }
}

public class PersonRepository<T> where T : IPerson
{
private T m_person;

public PersonRepository(T person)
{
this.m_person = person;
}

public void Save()
{
// The Age property is available
if (this.m_person.Age > 65)
{
// Save to free bus pass database...
}
}
}


Sunday, July 18, 2010

Hello World!

I am a 28 year old software engineer and this blog is going to help me to leave (a hopefully valuable and relevant) internet footprint. I can be found on Twitter and am also as a fledgling user on StackOverflow.

I watched a very interesting presentation from Scott Hanselman yesterday where he postulated that every developer should have a blog. If you think you don't have time, then think of all those long emails you write up every week that only reach an audience of maybe 4 or 5 people and are never seen again. Why not put your keystrokes and time to better use and write a post on your blog? Thank you Scott for inspiring me to start this blog. If I write one post that is even 1/1000th as relevant or interesting as the posts on hanselman.com I will have achieved something...