There is indeed a cost associated with using it i.e. every time you use it, you’re effectively creating a new anonymous type to hold that plus whatever the previous result in your query pipeline. So if you chain up lots of lets in a query, that’ll have an impact on the query. However, there is a case where let can give large performance benefits: -

Compare that code with the following: -

This will eliminate a massive number of calls to Convert.ToInt32() and reduce the time taken to process that query by around 40%; the former sample took ~1400ms to run whereas the latter took only around 800ms.

Why? Because it can be incredibly unslow. I’ve not had a look at the source code so can’t know exactly, but as I recall, the way that Unity deals with OptionalDependencies when they are not available is by throwing an exception, which is then caught and supressed by itself.

Performance varies depending on the type of object and the number of constructors it has (among other things), but, for example, missing Strings that are marked optional are incredibly slow if not available – sometimes upto 50x slower to construct an object.

This might not be noticeable if you just create the odd object here and there – but if you start doing anything heavyweight, you’ll soon notice it – so avoid it wherever possible.

Generic Types and Composition

Generics in C# are great. They give so many elegant ways to solve common problems and to implement certain design patterns that without generics would involve lots of boilerplate code. One of the things that they are great at is writing composed objects. For example, let’s say we wanted to represent a binary tree structure in C#. It might look something like this: -

Seems logical, doesn’t it? We have our properties which represent the data of a tree node, and a constructor that takes in the item that the node holds. Great – you can now have a tree node for any type e.g. Node<String>, Node<Int32> etc.! However, when you try to start using it and creating nodes in code, you’ll immediately come across a small problem: -

See the issue? Every time you want to create a Node of type T, you have to explicitly specify T in the type definition, even though we’re passing in an object of type T into the constructor. Seems a bit pointless, doesn’t it? Can’t the compiler “figure out” the definition from the constructor argument?

Generic methods

Luckily, there is indeed a way to achieve this effect through a generic method which acts as a factory – as long as it does not belong in the generic Node<T> class! Check this guy out: -

This method lives in the non-generic Node class. We can easily consume it as follows and thus create nodes much more succinctly: -

Sure enough, the nodes are correctly typed just like before e.g. Node<String>, Node<Employee> etc., but now a lot of the fluff has been removed – based on the type of the constructor argument, the return type will be inferred by the compiler. C#’s type inference perhaps isn’t as powerful as F#, but it’s really not that bad

Also notice that we’ve put the factory method in a class called Node – again, this aids the developer in terms of discoverability as it sits alongside Node<TItem>.

Conclusion

You might often find yourself putting generic methods into non-generic classes that themselves return generic objects.

There are many occasions when you may find that you need a non-generic base / sibling class for your generic classes in order to easily construct them, or deal with a set objects of a particular generic type that differ only by their type parameters e.g. Node<String>, Node<Int32> and Node<Employee> – having a non-generic base class called Node with common properties or methods allows you to deal with all instances of all Nodes in one go.

What is a framework?

Whenever you write a reasonably-sized application, you’ll probably end up writing some sort of bespoke “framework” in your application. When you start writing it, the idea sounds great up-front – you’ll write something that will save hours in future! No-one will have to worry about anything, the “framework” will take care of it all! You’ll talk about abstraction and encapsulation etc. etc.. and tell yourself it’s best practice to do it.

Developing Horizontally

There’s just one problem with writing generic, catch-all frameworks – and that’s that more often than you think, it’ll be completely unnecessary. You’ll start by writing some business code. Then you’ll think to yourself, “Hmm, this bit of code seems like it’ll be useful to the team at some point in the future. Let’s write some helper classes and integrate it with our framework so other people can reuse this bit of code.”.

This is what is known as “horizontal development” i.e. developing frameworks and cross cutting concerns rather than developing business functionality.

The biggest problem with horizontal development is that often this code reuse never happens; you end up with abstract factories with just one or two types being returned, or whole class hierarchies being written when it would have been ten times quicker just to manually compose some classes together a few times. Even worse, sometimes you’ll guess wrongly how you’ll end up using the framework and end up boxing yourself into a corner and having rigid and viscous designs i.e. the framework blocks you from doing what you want, and you end up having to work around it.

Developing Vertically

Developing vertically is the idea of developing features end-to-end that cut across all tiers, and developing just the part of every tier that you need to fulfil that feature; as you develop more features, your framework should naturally and organically evolve. You’ll refactor existing business logic to take advantage of your improved framework to make your code more succinct and easy to understand within the context of the domain. Your unit tests will protect you from breaking changes in your framework as you refactor and enhance it.

How do we go about doing this? I tend to strongly follow the Uncle Bob school of thought here, plus the 80/20 rule. This boils down to the following: -

Do you know for a fact that this bit of code is going to be reused, right now, somewhere else? If the answer is “no” – don’t do it. Wait until you need it the second time and then consider doing it then. You’ll be surprised with how many times you end up leaving things as-is. Obviously, it’s not black and white – if it’s fifty lines of code I’d be more inclined to refactor it into a reusable method / class than if it were one or two lines.

There are many examples of this sort of situation that you might come up against every day: -

• Having a constant in a method / class versus having a shared constants class / enum
• Hard-coding something versus making some sort of generic / abstract factory
• Using explicit / hard-coded values or classes versus abstracting it to the database (do you really need run-time configurability?)
• Writing some screens that look similar versus writing a generic “control factory” that generates UI for you etc.

In all these cases I would choose the simplest, cheapest option and only if I could prove through the codebase that we would benefit from abstracting the code away would I do it.

There’s one exception to this rule: when the cost of doing it later will be excessively high and would require a lot of effort to do retrospectively. Obviously this decision requires a judgement call on your part on an instance-by-instance basis as to whether it’s a real risk or not, and what the likelihood of it happening is. In such situations, I would either absorb the cost up front, or try to protect myself against this sort of thing where possible e.g. in the example above relating to a factory, a decent halfway-house might be to make a factory class but hard-code the implementation to always return the same type of object, so that you can easily expand it later without impacting lots of places.

Conclusion

Whenever you are faced with this sort of situation, I always ask myself questions like: -

• What’s the cost/benefit of doing this?
• Are we ever actually going to use this in the future, or is it just “in case”?
• How discoverable will my framework classes be?
• Am I going to document the framework and make it easily available to the rest of the team – otherwise there’s little point in having it.

There’s always a cost of having duplicate code everywhere – but there’s also a cost of having a framework that’s unnecessarily complex.

Problems with using IDisposable

In this post I want to expand on the previous examples to illustrate a more general solution to that problem. In the previous post, all the examples implemented IDisposable directly in order to participate in the using statement. However, there are reasons why you might not wish to have this coupling: -

1. Having a type implement IDisposable that has nothing to do with reclaiming of resources is somewhat misleading e.g. changing the console colour or the cursor icon. This is not what IDisposable was created for and can lead to confusion.
2. We may not always want to call the “on” action on construction of the object; perhaps we want to use it in other scenarios.
3. Compile-time tools such as Code Analysis and Coderush etc. may complain if you do not implement IDisposable in the “proper” way (with the Boolean overload) etc.

ISwitchable

There’s a way around this by making a new interface which I call ISwitchable, which is implemented by any classes that we want to use within the Using statement yet don’t want to implement IDisposable on (for the reasons outlined above).

Obviously, when we call “On” we’ll do the “on construction” action, and “off” will do the equivalent of the “Dispose()” call.

The DisposableAdapter

So, how do we use ISwitchable within the context of the Using statement? Well, we can’t directly – obviously the using statement only works with IDisposable – so we use the Adapter pattern. This pattern shows how we can “massage” an object implementing one interface into another interface – in our case, from ISwitchable to IDisposable. We therefore create an adapter class which takes in an object that is of type ISwitchable and adapts it to work with IDisposable: -

And here’s a (cut-down) version of the code for the adapter. All it does it delegate calls from the constructor to On, and Dispose to Off: -

Then we use it as follows, with the results below: -

• CodeTimer simply starts a Stopwatch on On, and stops it (and outputs the time) when Off is called.
• ConsoleColourInverter swaps the foreground and background console colours whenever On and Off are called.

So, we get two of these switchable “behaviours” applied onto our code; they start automatically, and then remove themselves once the using statement goes out of scope (as can be seen by the timer finishing and the console colour resetting itself). We don’t have to worry about exceptions either in the sense that because this is in a using statement, the finally block will automatically call dispose on both DisposableAdapter instances, which in turn delegate to the ISwitchable’s Off() method.

Conclusion

This is kind of reminiscent of aspect-oriented programming i.e. we’re applying a set of behaviours around some code and letting them do the work without us getting involved. Through the use of the Adapter pattern we have completely decoupled ourselves from IDispose, and with some use of generics are able to use these switchable objects within the context of a using statement pretty succinctly.

Defines a method to release allocated resources.

In the remarks section it states this: -

The primary use of this interface is to release unmanaged resources. The garbage collector automatically releases the memory allocated to a managed object when that object is no longer used. However, it is not possible to predict when garbage collection will occur. Furthermore, the garbage collector has no knowledge of unmanaged resources such as window handles, or open files and stream

However, there is a secondary use for this interface which has absolutely nothing to do with the GC or memory allocation etc.. It comes into being because of the way that the “using” statement works in C#, which behind the scenes, simply calls Dispose() for us once the using statement goes out of scope (in a finally block). We can use this to our advantage in a number of situations where you want have the following behaviour: -

1. Turn on something
2. Do some code utilising that something
3. Turn it off again

Consider the following (contrived) example – we’re in a dark room and want to write out some text on a keyboard; in order to do that we need to turn on the light whilst we’re typing, and then turn it off when we’re finished: -

A more elegant way might be as follows: -

This is a much more readable version of code; it’s implied from the using statement what the scope of the light is. All we have to do is implement IDisposable on our Light class, and on the constructor and Dispose call the appropriate methods (bear in mind that Dispose gets called automatically once the using statement goes out of scope).

Easy. There are many situations where this pattern could be applied that have nothing to do with managed resources: -

• Temporarily changing the console colour and then having it go back to what it was
• Changing the mouse pointer to an egg-timer whilst doing some time-consuming operation and when it completes resetting it
• Starting a Stopwatch when an operation starts and stopping it when it completes
• Changing some settings on your UI e.g. writeable / read-only etc. when in a particular application state etc.

In short, anywhere that you want to “temporarily” set the state of something and then reset it again. You can also chain them up: -

Nice. In my second post, I’ll discuss a way of generalising this class of problem and how we can decouple ourselves from IDisposable yet still retain the benefits of the using statement.

Second – expression trees. I just wanted to post a short blog about the actual cost of creating trees that can be illustrated by comparing the following two code samples: -

See the difference? Rather than creating the expression inline of the for loop (Sample A), we create it once outside the for loop and reuse it for all iterations (Sample B). (FYI: ParseExpression() does absolutely nothing – it’s just there as a means to an end). Here’s the timing results for 1,000,000 loops: -

Running the performance tuning wizard against this shows us some cheeky reflection calls behind-the-scenes which even brings up a performance warning: -

The lesson to be learned? Expression Trees are an extremely useful tool in your arsenal – and can be used to give big performance gains over e.g. reflection or even dynamic, but ensure that you cache the expressions themselves otherwise the cost of creating the tree can outweigh the benefits gained from them.

Many of these points I’ve recently been dealing with myself whilst having a team of developers joining a team I’m working in; when documenting some of the API and framework, I realised that it was not as easily discoverable or navigable as it could be; the next time I work on a reusable API, I’ll bear these points in mind more. I’d also recommend having a read of Framework Design Guidelines, which I read not too long ago and really opened my eyes in a number of ways to framework design.

• Make your classes discoverable. I can’t stress this enough. The namespaces of your API should be easy to navigate, logically laid out and as readable as possible. Put yourself in the shoes of another developer who types MyApplication. in Visual Studio. When they press that “.” key, Intellisense is going to pop up and show them the different areas they can look through. This needs to be as clear as possible in order to guide them through the API; when I start trying out a new API, Intellisense is my first port of call – I certainly don’t start by reading all the documentation on every class.
• Distinguish between 80/20 classes. It’s tempting to simply place all your classes that fulfil a particular function into a single namespace, but this often doesn’t help the developer. Instead, consider making a sub-namespace which contains more advanced features or classes (used 20% of the time) and keep the more common ones (used 80% of the time) at the higher, more easily discoverable, namespace. Also be strict regarding encapsulation – don’t make classes / methods / properties etc. public unless you need to.
• Do not use department names in your namespace. Physical departments are always changing. At the end of the day they usually really have nothing to do with your API. If your department is restructured or renamed, will your code magically stop working? I would even go as far as to say for internal applications, do not include the company name either – what’s the point.
• Beware of rigidly following the “namespace must be a child of the assembly name rule”. If we had an assembly called e.g. “MyApplication.Framework”, all code in that assembly should theoretically go underneath the MyApplication.Framework namespace. However, as an API developer, you might want very frequent and popular classes not to be buried away underneath the Framework level – you might want a developer to simply type “MyApplication.” and see the 4 or 5 most important classes that your API has to offer because that’s all that they might need most of the time. Indeed, they might have nothing to do with one another in terms of functionality – perhaps one is to do with logging, another to do with eventing etc.. It might sometimes be better to have an assembly which does not following the System.Subsystem.BlaBla naming convention and instead is simply called “BlaBla” – you’re not implying a namespace from this so are free to put stuff in any namespace.
• Don’t be concerned with file navigation. Don’t worry that the developer cannot infer at a glance what assembly a particular class lives in. They can hit F12 and be transported to the source code (or metadata) of the class immediately; they can use Solution Navigator to find the file, or have Solution Explorer follow the active file etc.. That should not be your main concern when designing your API.

Let’s say we have the following type hierarchy:

Easy enough. Now we want, for some arbitrary reason, to write a generic method that will set a specific integer property to the value of 25, but we don’t know which one it is. In our example above, that could be both the Age of the employee, or the AddressId. You could do this with reflection: -

Expression Trees

Nice. This works well, no problems whatsoever. There is another, strongly typed way of doing it though, with expression trees. By passing in an expression tree that navigates to that property, we can, at runtime, construct a Action method specific to what we want, and then call that method as needed. Here’s how we would consume such a method: -

ageSetter and addressIdSetter are two delegates that we are constructing at runtime to perform the task of setting the appropriate property to the value of 25. The main benefit of such an approach is obvious i.e. strong typing. But there’s another, more subtle benefit of such an approach – performance. To understand why this is, we need to understand how this method is implemented.

CreatePropertySetter returns an Action<T> which, when called, will set the appropriate property to 25: (I’ve elided the GetMembersEnumerator method for clarity)

To make it a bit easier to see what happens, when we call the method with e => e.Age, here’s what the above method looks like with debugger quickwatches pinned: -

By compiling the final expression, we get a proper Action method which is the same as instance => instance.Age = 25, except we’ve constructed this code, at runtime.

I find Expression Trees difficult to get my head around. I understand the idea of them – essentially building up a tree of things like “assign property” and “call method” and “if” etc. which can then be compiled into a lambda. But the Expression API has lots of factory methods and many ways to do the same thing; I guess with time you gain familiarity with the API, but it’s definitely not the easiest thing in the world to get your head around. Worse still, look at the code required to do the same thing as that reflection code – much more effort and much less readable.

However, where performance is concerned, Expression Trees will beat Reflection by miles – as long as you cache the Action method that is generated! The construction and parsing of the expression trees required to create the Action is an expensive operation, so you should cache the Actions. Once you’ve done that, the cost is extremely low, as you are simply calling an action method, almost the same as if you had written it yourself. For example, to set both the Age and AddressId properties to 25, for 2.5 million Employees, I observed the following timings: -

Type of code applied	Time required (ms)
Direct assignment	144
Reflection	3,881
Expression Trees	349
Dynamic	597
Hard-coded lambdas	136

Obviously the other three options wouldn’t be appropriate for the problem at hand (generic property assignment) but I wanted to illustrate how these two mechanisms performed. By the way – notice how much quicker dynamic is than reflection (and these timings were obtained when caching the property info objects as well). Funnily enough, if I wrote hard coded lambdas e.g. instance => instance.Age = 25 and used them, they outperformed code like instance.Age = 25. Why?

Conclusion

When you next use reflection for some property assignments or method calls, think about using Expression Trees, particularly where performance is a factor. Expression Trees are time consuming to write and understand, but offer superior performance and can be consumed in a strongly-typed manner. Alternatively, consider the use of dynamic where possible – again, for property setters and getters and method calls it offers better performance than reflection, and whilst obviously not strongly-typed, the code is again far more readable.

Before I start, this isn’t an “elitist” rant of mine! Now that that’s out of the way…

One thing that often gets on my nerves when interviewing developers is when people rate themselves out of 5 for a particular technology. Generally people tend to rate themselves on the following scale: -

• 3: I have used this technology a few times and know what it is.
• 4: I have used it on at least one project before.
• 5: I have been using it for a while and think that I know it to the fullest.

There is no 1/5 or 2/5 of course. No-one ever gives themselves 1 for a technology on their CV (after all, why bother saying you’re crap at something). And the worst part is, all this rating does is show how much you know that you don’t know in the subject matter. Let’s take C# as an example. Someone might know the following: -

• how to create and use generic collections, and understand the benefits from a usability point of view over ArrayList
• how to use e.g. foreach loops and basic flow control
• they might know how to use LINQ queries on a LINQ-to-SQL data context

However, they may not be aware of: -

• how to create their own generic classes, or how generics work underneath
• what is the yield keyword and how it can be of use
• what is the difference between IEnumerable and IQueryable, or what an expression tree is

That’s all fine. But as far as this person is aware, they’re a 5/5 C# developer because they aren’t even aware of what they are missing out on. Perhaps they give themselves a 4/5 “just in case” there’s a keyword that they might have missed Whenever I interview people, I’d much rather someone give themselves a 2 or 3 out of 5 and be honest about it – or perhaps surprise us with what they know – rather than big themselves up and then fall at the first hurdle. All that does personally is fill me with suspicion – after all, if they’ve given themselves a 5/5 for something and been caught out so quickly, all the other aspects of their CV should be treated with the same suspicion.

My personal advice would be that unless you can back it up, don’t do it.

For what it’s worth – and I don’t consider myself an expert in it – here’s the sort of things I would look for if someone rates themselves out of 5 in C# (note I have tried not to mention things like design patterns etc. etc., but rather just knowledge of the language itself, and I suppose its relationship with .NET as well): -

• 1/5: Understanding of basic control flow; try/catch statements; methods and  overloading; difference between static and instance members; properties; levels of encapsulation; object scope.
• 2/5: Able to explore and consume new simple APIs with little guidance. Consume and understand generic methods and classes; can create standard LINQ queries and consume IEnumerables / IQueryables. Good understanding of value and reference types, boxing and disposing of objects. Good understanding of object lifetime and the GC. Understands Reflection and its pros/cons.
• 3/5: Deep understanding of generics. Good understanding of the components of C#3 e.g. Extension methods, lambdas, expression trees etc. Comfortable with usage of Action<T> and Func<T>. Understanding of multi-threaded processes.
• 4/5: Good understanding of the role of the compiler in C# and its relationship with the .NET runtime. Good understanding of yield keyword. Understanding of closures. Knowledge of Task<T> and it’s relationship with threads. Understanding of dynamic, both in consumption and the underlying technology.
• 5/5: Expert level in nearly all areas e.g. compiler behaviour, memory allocation, expression trees, GC behaviour etc. etc. Perhaps your name is Eric Lippert, Anders Hejlsberg or Mads Torgersen etc. etc.?

I guess even someone like those individuals that I mention don’t know “everything” and the language because C# and it’s relationship with .NET is now so vast, and so complex, that no-one could possibly know the intricacies of every component of the language.

Now, I bet that people could write some great systems with just a 2/5 or 3/5. I would also say that there is little relationship between someone writing fault tolerant, readable and maintainable code and their knowledge of the language. All it means is that you have more tools at your disposal when faced with a problem; the challenge is knowing when to use the right one for the job at hand.