The product of a web developer with a little too much caffeine

Posts Tagged ‘Tips and Tricks

Null Instance Extension Methods

with 4 comments

Checking for null can be time consuming and add a lot of extra noise to the code you write. In some ways it can reduce the readability of your code and obscure the purpose of your functions.

For example, check out all of the null checks required for this bit of code.

public static int GetVersion() {
	//check if this exists
	if (!File.Exists(PATH_APP_DETAILS)) { return DEFAULT_VERSION; }

	//try and load the document
	XDocument document = null;
	try {
		document = XDocument.Load(PATH_APP_DETAILS);
	catch {
	if (document == null) { return DEFAULT_VERSION; }
	//find the element
	XElement release = document.XPathSelectElement("app/release");
	if (release == null) { return DEFAULT_VERSION; }
	//get the value
	XAttribute version = release.Attribute("version");
	if (version == null) { return DEFAULT_VERSION; }
	//convert the version
	int current = int.TryParse(version.Value, out current) ? current : DEFAULT_VERSION;
	return current;

Yikes… that is a lot of code for such a small task but what else can you do? You can’t just call methods on something that is null or your app is going to blow up… or can you?

Null Instance Extension Methods

Extension methods feel magical the first time you see them in action but ultimately they are just static methods that can be invoked from anywhere in your project.

But here is the neat thing — Since an extension method isn’t tied to the instance of a class then they can be invoked without an instance of the class.

Sound confusing? Here is an example of what I mean…

//create an extension method
public static class StringExtensions {
	public static void Test(this string value) {
		Console.WriteLine("Hello from a null test!");

//and then call it
string nothing = null;
nothing.Test(); //ok!
nothing.ToUpper(); //crash

You’ll notice that the call to Test worked fine – If you put a break point in the method and check the value argument then you’ll notice it is actually null! We were able to call the method Test even though there wasn’t an instance of a string.

So how can this help us? Well let’s take the same XML problem from earlier in the post and create some extension methods that don’t care if the instance being invoked is null or not.

//helper extension methods for XML documents
public static class XmlExtensions {
	//loads an xml document to use
	public static XDocument LoadDocument(this XDocument document, string path) {
		if (!File.Exists(path)) { return null; }
		try { return XDocument.Load(path); }
		catch { return null; }
	//uses an XPath to find an element
	public static XElement GetElement(this XDocument document, string path) {
		return document is XDocument ? document.XPathSelectElement(path) : null;
	//returns the value of an attribute
	public static string GetAttribute(this XElement element, string name) {
		XAttribute attribute = element is XElement ? element.Attribute(name) : null;
		return attribute is XAttribute ? attribute.Value : string.Empty;

Now let’s take a look at how we can solve the same problem as before but with these new extension methods…

public static int GetVersion() {
	//open the document (Mono)
	XDocument document = document.LoadDocument(PATH_APP_DETAILS);

	//It appears you have to do it like this in Visual Studio
	//XDocument document = ((XDocument)null).LoadDocument(PATH_APP_DETAILS);
	//find the element
	XElement release = document.GetElement("app/release");
	//get the version
	string version = release.GetAttribute("version");
	//convert and return the value
	int current = int.TryParse(version, out current) ? current : DEFAULT_VERSION;
	return current;

As far as I can tell, no matter what you throw at this code, you will either get the default version or the value in the XML document. This definitely reduces the lines of code count… but the clarity gains might be debatable.

  1. A developer modifying this code might not realize the value could be null or could be a real object. If they call an instance method and the value ends up being null then the application is going to crash.
  2. Some developers are going to scratch their heads when they read the line XDocument document = document.LoadDocument(...). Invoking a method on a value you’re declaring and should be null and returning the result it to itself? Huh?
  3. The more forgiving your code is then the more prone to external errors it will be, which in turn will introduce subtle runtime errors in your applications. Sometimes it’s a better idea just to throw an exception and keep the program from running.

So, while this approach has benefits it also has pitfalls. Make sure to evaluate the risks before using something like this in your code. If implemented carefully this could reduce complexity in your application…

…or at least make for a neat parlor trick the next time you’re with your dev team.

Written by hugoware

August 22, 2010 at 9:14 pm

Avoiding Confirmation Boxes

with one comment

One thing I try to avoid in interface design is unnecessary user interaction – Basically, asking the user for feedback when it isn’t needed. The area that probably bothers me the most are “confirmation boxes” – Especially those that block the entire application until you’ve clicked ‘OK’?

I’m not really sure why you see them so often in applications since I’m pretty sure that users and developers alike probably get tired of seeing them. Not only that, studies have shown that they are mostly ineffective, normally only earning a cursory glance before being dismissed.

So what can you do instead?

Don’t Confirm Success, Notify On Failure

Probably the easiest and quickest improvement to an application is to stop confirming when your application worked. How many times have you seen this pointless little window pop up?

Uh, yeah…

For the most part, a user should be able to assume that their “request completed successfully.” — Otherwise, why the heck did they buy your software to begin with?

Instead, pop up a modal dialog box if something goes wrong and their request didn’t work. This is a much better time to interfere with user work flow.

Allow Permanent Dismissal

New users of an application don’t mind confirmation boxes as much since they are still poking around and trying to figure out what everything does. But after the 10th or 15th time the ‘your request has been completed!’ message is starting to wear on them.

Sure, it was helpful at first but now that they know the expected behavior, the additional confirmation is an annoying extra click.

Ah, now that is better. I’m confident using this part of the program – stop bugging me!

Even Better – Don’t Confirm, Make It Easy To Undo

Remember the computer before the undo button? It was painful and frustrating, but then one day like magic we could fix our silly fat-finger mistakes – Genius!

What about the Internet before the undo button? Oh… wait. The ‘undo’ button is actually still pretty uncommon in web applications. Of course, web applications aren’t the only area that this applies – but it is still possible to make it happen. GMail is a great example of how this applies to any application – including the web.

The message explains what happened and gives immediate actions for the two most probably user responses – “What the heck did I just do?” and “Oh snap, I didn’t mean to delete that!”.

Use Visual Indicators As Confirmation

Visual indicators work well as additional confirmations. If you make it clear enough what a user is about to do then normally you can avoid a confirmation box.

Red highlights, short and clear sentences, explanation of the final result – All of these items act as an additional confirmation for the user to understand the result of their action. To take it a step further, the text on the button OK would be even clearer if it said Delete (see how easy this is!)

It doesn’t take much to reduce, and in many case eliminate, the dialog boxes we pop up in our applications. You’ll be happier, your users will be happier — Heck, I’ll even be happier even if I never use your application.

What are ways you can use to limit the number of dialog boxes you use in your applications?

Simple External Templates With jQuery

with 4 comments

New code available: I’ve written a follow up post about this topic with new code and new features.

If you’ve ever tried building a jQuery object from scratch then you’ve probably found that it is a little time consuming and probably a little ugly by the time you’re finished. You could put additional HTML templates as hidden elements on the page but maybe you’d rather keep that extra mark up out of your page.

One option would be load a template from a website address and then make your changes once it arrives. The code would probably look something like this.

//create the container
var element = null;

//make the request for the HTML
    success:function(html) {
        element = $(html);
        //make changes here

There isn’t anything wrong with this code but it does put a bit of separation of your declaration of an element and the actual usage of the element. The problem is that you can’t do the whole process at once since the AJAX call takes a little time and you have to rely on a call back before you have access to the object.

It would be nice if we could have immediate access to our jQuery object on an AJAX call, but not block anything else on the page.

Time For Some Javascript Magic ™

I’m not really sure what you would call the example below, but the general idea is to capture (and queue up) any actions that would be invoked on our jQuery object and then release them once the AJAX call has been finished.

Let’s look at some code and see what it would look like (extra comments to try and explain the process)

 * Arguments
 * $.template(url) - Pass in a string to a url to load 
 * $.template(params) - An object with parameters found below
 *   url: Path to the template resource (required)
 *   data: Same as the 'data' argument in the $.ajax call
 *   error: Same as the 'error' argument in the $.ajax call
 *   complete: Same as the 'complete' argument in the $.ajax call
 *   beforeUpdate: delegate(html) called just before the actual object is created
 *   afterUpdate: delegate(html, actual) called just after the actual object is created

//creates a function to access a web template
jQuery.template = function(params) {
	//format the passed in parameters
	//check if this was only the resource url
	if (typeof(params) === "string") {
		params = { url:params };
	//prepare the arguments passed into the class
	if (!$.isFunction(params.beforeUpdate)) { params.beforeUpdate = function() {}; }
	if (!$.isFunction(params.afterUpdate)) { params.afterUpdate = function() {}; }

	//create the object that handles the work
	var self = {
		//handles forwarding methods onto the actual object
		//the actual jQuery object being created
		//method calls that are waiting to be called
		//prepares the container for use
		setup:function() {
			//apply each of the methods
			self.container = $("<div/>");
			for(var item in self.container) {
				if (!$.isFunction(self.container[item])) { continue; }
		//handles creating method forwarding on the returned object
		register:function(method) {
			//create a method that handles routing the original method calls
			self.container[method] = 
				function(p0, p1, p2, p3, p4, p5, p6, p7, p8, p9, p10, p11, p12, p13, p14) {
				//if the actual object has been called, just invoke
				if (self.container.actual) {
					return self.container.actual[method](
						p0, p1, p2, p3, p4, p5, p6, p7, p8, p9, p10, p11, p12, p13, p14
				//otherwise, queue the request
				else {
						params:[p0, p1, p2, p3, p4, p5, p6, p7, p8, p9, p10, p11, p12, p13, p14]
					//then return the temporary object
					return self.container;
		//executes any queued commands and updates the jQuery object
		update:function(html) {
			//create the jQuery object
			self.container.actual = $(html);
			//then execute all of the waiting commands
			$.each(self.queue, function(i, arg) {
					arg.params[0], arg.params[1], arg.params[2], arg.params[3], arg.params[4],
					arg.params[5], arg.params[6], arg.params[7], arg.params[8], arg.params[9],
					arg.params[10], arg.params[11], arg.params[12], arg.params[13], arg.params[14]
		//starts the ajax request to download the template HTML
		download:function() {
			//starts downloading content
				//parameters for the template request
				//performs the catch up work for the ajax
				success:function(html) {
					//** Optional: Uncomment 'setTimeout' to simulate a delay 
					//setTimeout(function() {
					params.afterUpdate(html, self.container.actual);
					//}, 2000);
				//additional handling of the request
		//setup the object to work
		init:function() {
			//prepare the temporary container
			//start downloading the content;
	//prepare the the template code
	//return the custom container to forward method calls
	return self.container;

This code allows you to have direct access to a jQuery object even before it has finished loading the content from the server. So, instead of using a callback we can write our jQuery like we normally would.

//note: the first command is all one long chain with a comments
//between functions to explain a bit more

//create the object and immediately apply changes
var template = $.template("template.txt")
	.css({"color":"#f00", "width":"200", "background":"#333"})
	.animate({width:800, height:900}, 3000)

	//you can even append and appendTo the object in advance

	//or search for and update child elements

	//and parent elements
//you can also still access the template from the 
//assigned variable
template.find("div").click(function() {

//even if if you call it much later, it still works
setTimeout(function() {
}, 10000);

What Is Going On Here?

As I mentioned before the real problem is that the jQuery object we create isn’t ready as soon as we want to assign to it. Because of that we have to use a callback to resume the work. However, the cool thing about dynamic languages is that we can override anything we want.

In this example we start by creating a container that has all the same functions as a typical jQuery object but has one slight modification — all the methods are overridden and placed into a queue (man, I love enclosures). Once our AJAX call has completed we run an update command that executes everything we have saved against our new jQuery object instead of the one that received the calls to begin with — madness!

After we’ve caught up and our actual object is created we can stop saving actions to the queue and instead just invoke them immediately. I nicknamed this method forwarding for the sake of having a cool, buzzword sounding sort of name but if anyone knows what this is really called, please tell me 🙂

It is worth noting that this is only going to work with functions that return the jQuery object (at least until the ‘real’ object is created). The reason is that since we’re just capturing methods and saving them for later then we don’t know what the actual return type is. Needless to say, using a property probably won’t be accurate either (since we can’t intercept the request for the property like we would with a method)

In any case, this might simplify the next time you need to download content in jQuery but you don’t want to break up your functionality.

Written by hugoware

January 14, 2010 at 10:59 pm

Using Delegates As Parameters

with 2 comments

I’m not sure the community stance on passing around delegates as arguments but personally I love it. I think there is something magical about the way you can provide instructions on how how to do something and then pass it into another method and let it do its job without needing to think about it. It is almost like writing a code template and then filling in the blanks with the specifics of what you need.

Using delegates as arguments can simplify code and in some cases reduce it. This post goes over a sample scenario where you might use delegates as arguments instead of writing multiple functions to perform different tasks.

Simple Resource Loader

Let’s pretend we have a class that is responsible for loading and saving files from an external resource. We could write a class like the one below.

//handles loading resources for the application
public static class ResourceLoader {

    //returns the bytes for a resource
    public static byte[] LoadBytes(string resource) {
        string path = ResourceLoader._GetResourcePath(resource);
        return File.ReadAllBytes(path);

    //returns a xml document resource
    public static XDocument LoadXmlDocument(string resource) {
        string path = ResourceLoader._GetResourcePath(resource);
        return XDocument.Load(path);

    //returns a bitmap resource
    public static Bitmap LoadBitmap(string resource) {
        string path = ResourceLoader._GetResourcePath(resource);
        return Bitmap.FromFile(path) as Bitmap;

    //returns the string text for a resource
    public static string LoadText(string resource) {
        string path = ResourceLoader._GetResourcePath(resource);
        return File.ReadAllText(path);

    //generates a path to a resource
    private static string _GetResourcePath(string file) {
        return Path.Combine(@"c:\path\to\files\", file);


Nothing is really wrong with this code. If we need to add a new type to this class then we simply create a new method and plug it in. Additionally, each of the methods could use some sort of exception handling in case the conversion doesn’t go so well. As you can imagine, the more try catch blocks we add, the larger this class starts to get.

However, if you think about it, all of these resources could be handled roughly the same way. They all need a way to convert bytes to whatever type you’re wanting.

Using A Delegate To Fill In The Blank

So instead, lets address this problem using a delegate to handle the conversion of bytes to the type that we need.

//handles loading resources for the application
public static class ResourceLoader {

    //returns the bytes for a resource
    public static T Load<T>(string resource, Func<byte[], T> convert) {

        //find the correct path
        string path = Path.Combine(@"c:\path\to\files\", resource);
        byte[] bytes = File.ReadAllBytes(path);

        //attempt convert the file
        try {
            return convert(bytes);
        //if it fails, forward the error to the caller
        catch (Exception ex) {
            throw new FormatException(
                    "Could not load resource '{0}' as a type {1}", 
                    resource, typeof(T).Name
                    ), ex);



Great — Now we can provide any method we want to format the bytes and then return the type we’re looking for. So for example, instead of calling ResourceHandler.LoadBitmap we can use our new method as shown below.

Bitmap bitmap = ResourceLoader.Load("test.jpg", (bytes) => {
    using (MemoryStream stream = new MemoryStream(bytes)) {
        return Bitmap.FromStream(stream) as Bitmap;

Pretty slick, right? …oh, wait… this code is longer and more difficult to use… This can’t be right!

Bringing The Concept Together

Clearly, the example above isn’t improving anything for us. The code is longer and requires that we write the same functionality for reading a resource in multiple places. Even though this code is more flexible, it also requires more work. So instead, lets write some definitions of common conversions as part of our class.

//handles loading resources for the application
public static class ResourceLoader {

    //Load<T>(resource, convert)

    //converts bytes to a bitmap
    public static readonly Func<byte[], Bitmap> AsBitmap = (bytes) => {
        using (MemoryStream stream = new MemoryStream(bytes)) {
            return Bitmap.FromStream(stream) as Bitmap;

    //converts bytes to a xml document
    public static readonly Func<byte[], XDocument> AsXml = (bytes) => {
        using (MemoryStream stream = new MemoryStream(bytes)) {
            using (StreamReader reader = new StreamReader(stream)) {
                return XDocument.Parse(reader.ReadToEnd());

    //converts bytes to a string
    public static readonly Func<byte[], string> AsText = (bytes) => {
        return Encoding.UTF8.GetString(bytes);

    //simply returns the byte array
    public static readonly Func<byte[], byte[]> AsBytes = (bytes) => bytes;


Now, instead of needing to manually create a delegate to handle the conversion process we can write code like the example below.

//Loads a resource by passing the static delegate that is part of the class we created
Bitmap bitmap = ResourceLoader.Load("test.jpg", ResourceLoader.AsBitmap);

By using delegates as an argument we allow our loading function to be flexible enough to accept other methods for performing the conversion (that we can create as we need them) or the common conversion methods that we added as part of the class.

You’ll also notice that we don’t need to declare the generic type we’re wanting to have returned since it can be inferred from the return type of the delegate we pass in! (so cool… to me at least)

Of course, there is about a hundred different ways to can already load resources in .NET but you could apply this same concept many other areas of applications you develop.

How could you use delegates to create “templates” for code?

Written by hugoware

January 13, 2010 at 1:58 am

Minimize Context Switching

with 2 comments

I very rarely get to work on only a single project at a time when I’m writing code. Normally I have a couple projects going on at work plus a few extra at home. Add in a few blog posts and bug fixes in the mix and it starts to get really difficult to remember where you were at when you sit down to start working. Most people refer to switching between projects as context switching which normally has a very expensive cost in mental resources.

However, it really doesn’t have to be that way. You can minimize, and sometimes completely eliminate, the cost associated with context switching. Here are some ways I have found that has transformed my ability to work on multiple projects at once.

Minimize Complexity, Increase Clarity

Whenever I’m talking code with other beginning developers, this is the first point I start with. Complexity and clarity is one of the most difficult battles for a developer since the definition of ‘complex’ and ‘clear’ constantly changes.

Remember when reading contents a text file was difficult for you to understand? Now you can write an entire content management system in a single lambda expression. The perception of complex code diminishes over time for a developer but complexity of code never changes (too philosophical?)

The point is that just because you can understand large chunks of code doesn’t mean that it isn’t complex. Large blocks of code require a lot of time to read and comprehend, even if they are well documented — which adds significant context switching costs. Here are a few of the main points I like to discuss.

  • Always use clear names for classes, functions and variables — You’ll never regret naming a function employeeTotalSalary instead of just x
  • Keep functions short and specific. Limit the responsibility of a function to a single purpose. If you have a function that has multiple steps, then it ought to be in its own class.
  • Using named enumerated types as a return value from a function are often more clear than other responses such as booleans or nulls.

Be Consistent

Another point is to keep the way you code your project consistent. If a style of an project changes from class to class and function to function, then you can expect the cost of context switching to be dramatic.

For example, what if you chose to return ‘null’ in functions that encountered an error — but for only half of your project. Then, the other half of the project you threw exceptions. Each time you opened that project you would be forced to read code and remember all of the little details for each class and function you were working with.

On the other hand, if you were consistent with your approach, then after the first error you encountered you would remember how to deal with the rest of the project without needing to open a single file.

  • Be consistent with your approach to handling errors, passing arguments, cleaning user input.
  • Remember the ‘DRY’ Principle — Repeated code leads to inconsistent code. If you’re doing it more than once then you need to move your code into a single, well named function.

Test Driven Development

I’m not a huge advocate of Test Driven Development – I don’t think it solves nearly as much as many people suggest it does. There is a lot more to if an application is working than a series of tests can prove (for example, a website and browser rendering issues). However, TDD can go a long way to make you confident that your changes aren’t breaking existing functionality.

Because a single change could potentially break an entire system, you can’t just modify some code and then hope for the best. Instead, you have to spend a lot of time reading code and finding possible errors and then testing them.

Even if you aren’t an expert at the methodologies behind TDD, using Tests in a project is a great way to minimize the context switching costs. You can focus on making a change and verifying that you didn’t break any existing functionality.

  • Using tests is a good way to minimize context switching because you don’t need to understand the project to make a change.
  • You don’t need to be an expert to write tests — Just spending an afternoon researching TDD can go a long way

Don’t Stop Here Though…

Context switching is a difficult thing to deal with, but reducing complexity and improving your confidence in a project is a great way to make switching between projects easier than before.

These are just a few ideas that I wanted to type about tonight. I have a lot of other suggestions that I share with developers that I’ve learned over the years. Additionally, there is a lot of great information about managing code complexity on the web.

If you aren’t doing anything to reduce the complexity of your projects then you can always expect your context switching time to be a difficult transition — but the good news is that it doesn’t take much to reduce that cost and make your life easier.

Written by hugoware

December 28, 2009 at 12:19 am

Combining WebServices with MVC

with 7 comments

I always liked the concept behind WebServices. Having a single place to store a bunch of complex but commonly used functions is a great way to decrease complexity of other programs that all sit on the same network. If you’re like me and tend to do a lot of intranet applications, a web service can prevent a lot of duplicate code.

My only real problem with WebServices was having to use SOAP. Adding a Web Reference to a project wasn’t that big of a deal but if you ever wanted to just call a function real quick, say from a script file (yes, I do VBScript occasionally… ick) then it isn’t quite as I’d prefer. You end up spending more time making sure your XML is well formed and less time on the logic inside your quick script.

MVC helps get around that problem by allowing you to perform normal HTTP calls and plug all your arguments into the query string or the body of the request – something much easier to do. The problem, however, is that you end up losing the convenience of using a WebService with other applications.

A Simple Solution

The idea here is to create a controller that acts as a wrapper to a WebService. By doing this we can override a few methods on our Controller that use reflection to invoke the matching method on the WebService. Also, because the Controller is still a unique class, we can still attach any number of Actions to it as we normally would. Below is some code that I wrote the other day. It isn’t battle tested so if you use it be sure to verify it does everything that you need it to do.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Services;
using System.Web.Mvc;
using System.Reflection;
using System.Xml.Serialization;
using System.Xml.Linq;
using System.IO;

namespace Interface.Controllers {

    /// <summary>
    /// Abstract wrapper that handles calling WebService methods on behalf of a controller
    /// </summary
    public abstract class WebServiceControllerWrapper<T> : Controller where T : WebService {

        #region Constructors

        /// <summary>
        /// Creates a new Controller Wrapper for a WebService
        /// </summary>
        public WebServiceControllerWrapper() {
            this.Service = Activator.CreateInstance<T>();


        #region Properties

        //The service that is being used for this call
        private T Service { get; set; }


        #region Overriding Methods

        //finds the correct method for the WebService method
        protected override void HandleUnknownAction(string actionName) {

            //find if the method exists
            MethodInfo method = this.Service
                .Where(found =>
                    found.IsPublic &&
                    found.Name.Equals(actionName, StringComparison.OrdinalIgnoreCase) &&
                    found.GetCustomAttributes(typeof(WebMethodAttribute), true).Count() > 0

            //if no method was found, just give up
            if (method == null) { return; }

            //check if all the arguments were found
            List<object> arguments = new List<object>();
            ParameterInfo[] parameters = method.GetParameters();
            foreach (ParameterInfo param in parameters) {

                //check if this argument was found
                object arg = this.ValueProvider[param.Name].ConvertTo(param.ParameterType);

            //with the arguments try and call the result
            object result = method.Invoke(this.Service, arguments.ToArray());

            //if there is a return value, serialize it and write it
            this.Response.ContentType = "text/xml";
            if (method.ReturnType != null) {

                //if this is an XElement of some kind, just use it as is
                if (result is XObject) {

                    //write the string
                    using (StreamWriter writer = new StreamWriter(this.Response.OutputStream)) {

                else {

                    //try and serialize it
                    XmlSerializer serialize = new XmlSerializer(result.GetType());
                    serialize.Serialize(this.Response.OutputStream, result);






The idea here is to inherit this class instead of the standard Controller class and provide the name of the WebService we want to wrap around as our Generic argument. For example…

//that's about it - actions are mapped automatically to the correct method on the webservice
public class AccountController : WebServiceControllerWrapper<AccountWebService> { }

By doing this, when our controller receives an Action, is checks the WebService instance for the same method and then tries to call the method with the arguments it finds as part of the request!

And that’s it! A quick and simple way to map incoming actions to a matching method on a Web Service!

The Return Type

I’m not sure the best way to handle the return type at this time. It seems to me that the XmlSerializer should be sufficient for object with the exception of Xml which should probably just be written out as a string. If you have a suggestion on a better way to respond to incoming requests, please let me know. 🙂

Remember: This is just some quick and dirty code – This needs some more polish and exception handling before I’d use it in a real project, but at least it might help you get going in the right direction.

Written by hugoware

September 27, 2009 at 9:51 pm

Slightly Easier Recursive Functions

leave a comment »

I’ve joked before that recursive functions were the kind that make you “curse over and over and over and over…”. Granted, they aren’t the most difficult thing to do in programming, they can tend to require a little more focus to write correctly.

So when you work with a recursive function you normally need to create some sort of safety counter to prevent an infinite loop. If not you end up passing around your counter by reference which can be a bit confusing to developers in itself.

Not only that, it also tends to hurt the “black box” approach to class design. Even if the method is private you still need to prepare a safety counter in advance before you can call the method — a function that has a order dependency, which isn’t a good thing.

Lambda To The Rescue

I love working with lambdas – I think that I cried a tear of joy the day I realized they could be passed as an argument (actually, I didn’t… that would be weird).

So what if we created a single lambda within our functions that would perform all of the recursive logic inline?

public void ScanElements(XElement xml) {
    //create a safety counter
    int safety = 0;
    //declare the scan action as null at first
    //since we can't call it recursively inside
    //the method unless it is declared first
    Action<XElement> scan = null;

    //assign the actual work to do
    scan = (node) => {

        //increment the safety
        if (safety++ >= 100) { return; }

        //do the actual work here

        //and then recursively call the scan method again
        foreach (XElement element in node.Elements()) {

        //reverse the safety


    //now, actually start the recursive function here


Now, that isn’t too bad. We have all of our logic encapsulated into a single method that doesn’t require any setup before it is used. It might be a little odd to a developer that hasn’t used lambdas much, but a comment explaining what is going on should be enough to get them onto the right track.

Maybe this is a terrible idea – I’m not really sure but it does decrease complexity and improve encapsulation — even if it is with a single private method.

Using the .Descendants() method as part of the XElement/XDocument classes would be much wiser here – this code is just an example of performing a recursive method.

Written by hugoware

September 24, 2009 at 10:33 pm