Marius Gheorghe

Building software : make it work, make it good, make it fast

Saving a synchronization context switch with await

If you're not interested in using the result of a async method on a UI thread (which happends implcitely when awaiting a method from the UI thread), you can save a synchronization context switch by using :

await DoMyStuffAsync().ConfigureAwait(false);

Passing false to ConfigureAwait will prevent the switch to UI thread.

Async wrongly named

I was thinking that await keyword has to be one of most "wrongly" named keyword (volatile being the other contender) from the language. I noticed that most people when learn about async + await have the impression that the current thread "stops" when encounters the await keyword (obviously not the case).

Maybe "concurrent" or even "parallel" would have been better.

Good usage of extension methods

string.IsNullOrEmpty(stringInstance)
could be replaced with
stringInstance.IsNullOrEmpty()

by adding the following extension method :
public static bool IsNullOrEmpty(this string text)
{
return string.IsNullOrEmpty(text);
}

lambda functions vs anonymous methods vs code reading

Remember that code is written to be read and sometimes compiled and run ? Here are some code snippets comparing lambda function with anonymous methods from a code reading perspective : Anon method :

ds.ForEach(delegate(Developer d)
{
d.b = 3;
});

Lamda:
ds.ForEach(d = > d.b = 5);

While you have to love how small the code is, from the reading perspective this is pretty bad. It will be better if we add the args types :

ds.ForEach( (Developer d) = > d.b = 5);


Passing around anonymous types

You can't pass around (or return from a function) a anonymous type in C# 3.0 .If you want to do that you have to ""get"" the entire type. I see 2 particular problems with either of these approaches :
- get the entire type instance

var f = from d in ds
where d.b > 56
select d;

Let's suppose that ""d"" is a mapped ""Developer"" entity with 20 fields. Even if you need 2 fields you are forced to retrieve all 20 fields.

- get a subset of data

var f = from d in ds
where d.b > 56
select new { d.a, d.u };


In this case you have a anonymous type which you can't pass around so you'll need to make the binding/extra logic in the same function. This is really bad for separation of concerns.

Both compiler and interpeter

The CodingHorror dude posted a while ago about the C# compilation tax.
The gist of its problem is that you have to compile. All the time. Personally i have always thought that, at development time, compilation is stupid. It's a slow, unnecessary step which hampers the productivity. Ideally, at development time, the code should be interpreted. You should be able to make any source change and see the results immediately (think something like Edit and Continue on steroids). Then you should be able to compile the project and produce the assembly that will be redistributed. Unfortunately, event though there are languages that have both compilers and interpreters ( Boooooooooooooooo, the tools (Visual Studio) and infrastrcture (Common Language Runtime) are not, yet, up to the snuff. So, like the CodingHorror dude was mentioning, even though in theory we have the great 'we run over 40 languages' CLR, the reality is way different and only a handfull of languages can be used. To make the matter worse there are further complications. For instance only recently Microsoft has begun to work on a new compilation model for ASP.NET that allows for interpreted languages (this is included in the ASP.NET Futures package) but it's still far from useable today.
I would love to work with Boo in ASP.NET using the interpreter. But, unfortunately, it's not possible today.

A constant is not a "valid" API reference

A interesting thing about constants : when you compile a assembly (let's called it A.dll) which refers a constant defined in another assembly (B.dll) , the value of the constant is embedded at compile time and not a "reference" to it. So, later, if you update the value of the constant(in assembly B.dll) it won't be enought to replace the assembly to get the updated value, you will also have to the A.dll to get the updated value. It is a normal thing (after all you can't pass constants by reference) but i was still a little surprised when it happend to me.

Code guidelines- Returning multiple parameters

I'm currently reading "Framework Design Guidelines" and enjoying a lot. The book is tight packed with great information for designing solid APIs. While reading the book it happens that a lot of times i nod my head while thinking "yeah....yeah...that's exactly how it should be implemented". Some other times i don't really agree with the framework designers. For instance here is a quote about ref and out parameters in the context of returning multiple results from a function.

Anders Hejlsberg As a rule, I am not too crazy about ref and out parameters in APIs. A such APIs compose very poorly, forcing you to declare temporary variables. I much prefer functional designs that convey the entire result in the return value

Unfortunately i can't agree here because this recommendation conflicts with one of the most important guideline in software development : less code. . Here is an example. Compare :

public struct ResultInfo
{
private string name;
private int age;

public string Name
{
get
{
return name;
}
set
{
name = value;
}
}

public int Age
{
get
{
return age;
}
set
{
age = value;
}
}
}
ResultInfo info = this.GetMyStuff();


to this :

string name = string.Empty;
int age= 0;
this.GetMyStuff(ref name, ref age);


Less code = simpler = better solution from my point of view.

Implicit type conversions

Implicit type conversions are a very handy, and most of the time overlooked, feature the C# language that allow conversions between 2 types. While normally i would not recommand using implicit conversions (explicit is better for readability purposes) there is a case where implicit conversions make sense. In this case you change the signature of the public API and you customers won't be affected.

Suppose we have :
public A GetThis() { } In v2.0 you want to change the signature to public B GetThis() { }
Instead of deprecating the particular function and changing the client's code we simply add a implicit conversion to type B.
public static implicit A (B b) { }