Closure Tip

In C# 2 and greater you have the ability to write closures.  A closure is a function that is evaluated in an environment containing one ore more bound variables[1].  In C# 2 this is done by creating an anonymous method that accesses a variable declared outside the body of the anonymous method.  Writing closures (which can evolve from an anonymous method that is not a closure) must be very deliberate and must be given great attention.  Closures offer a very specific way of essentially creating code at runtime based on runtime values.  But, with closures, they can be bound to a mutable variable.  When you bind to a mutable variable you get the value of the variable when the closure is run, not when the closure was created.  You intuitively expect to get the value when the closure was created, not when it was executed.  For example


            String[] numbers = new[] {"one", "two", "three"};

            List<MethodInvoker> delegates = new List<MethodInvoker>();

            foreach(String number in numbers)

            {

                delegates.Add(delegate() { Trace.WriteLine(number); });

            }

            //...

            foreach(MethodInvoker method in delegates)

            {

                method();

            }

With this code, you would expect the following trace:


one
two
three


But, you get this:


three
three
three


This is because the anonymous method is bound to the variable number which was “three” when the anonymous method was executed.


But, what can you do to create an anonymous method at runtime that will output the value of a specific value in a collection?  Well, the answer is very simple, bind to a variable that doesn’t change.  For example:


            foreach (String number in numbers)

            {

                String text = number;

                delegates.Add(delegate() { Trace.WriteLine(text); });

            }

            foreach (MethodInvoker method in delegates)

            {

                method();

            }

The addition of the text variable that is simply initialized with the value of number means the closure isn’t bound to a mutating variable and end up getting results that are more intuitive:


one
two
three


In C# 3 you also have the ability to write closures in the form of lambdas.  You could do the same as the above with lambdas as follows:


            foreach (String number in numbers)

            {

                String text = number;

                delegates.Add(() => Trace.WriteLine(text));

            }

            foreach (MethodInvoker method in delegates)

            {

                method();

            }

Related advice may be found in Item 33 of Bill Wagner’s More Effective C#.


With Resharper you get an added warning that warns you that you’re accessing a modified closure.  So, in the first example, the IDE would show number as the WriteLine parameter as a warning.


[1] http://en.wikipedia.org/wiki/Lexical_closure


DotNetKicks Image

Developing with Source Code Control Best Practices Part 1

This post will detail some first principles about source code control (SCC) and provide what I consider the most basic of practices that every dev should follow.


What is SCC?
SCC provides developers the ability to keep a history of their changes.  SCC allows developers the ability to group file changes together with an annotation. SCC allows developers the ability to get back to the state the project was in at any given point in time, arbitrary or specific (Beta 1, RTM, etc.).  SCC provides development teams the ability to more easily work on the same files at the same time.  SCC allows developers to see who did what, when, and usually why.  SCC allows development on more than one branch of the code at a time.  Depending on the SCC, SCC allows developers to link changes to tasks, work items, etc.


Basic practices
Never check in changes that cannot be built.
This is pretty self-explanatory.  Referring back to what is SCC: “SCC allows developers the ability to get back to the state the project was in at any given point in time”.  This means anyone can get back to a state where the project won’t build if you check in changes that cannot be built.  This causes undue friction at points temporally distant from the changes–which means there lots of work (time) involved to find and implement a solution (e.g. is the state 5 seconds before better, is the state 5 seconds after better, etc?  All things that need to be researched and tested before continuing–wasting time and resources).


Check in related changes atomically.
This builds on the first practice, if all related changes are checked in as a unit the likelihood of that check-in breaking the build is highly improbable.  Atomically means all related changes are checked in at the same time.  With most SCC systems this is extremely simple, and usually means selecting all the files you have edited (or all the subfolders you have modified folders in–or the one subfolder if you have unrelated changes, see part 2).  This might mean avoiding SCC IDE integration if your changes span several solutions. If you can’t check in changes atomically (really question this if you think you can’t.  If you honestly can’t, I’d suggest changing SCC systems) order the check ins to avoid build problems.  For example, if you added an enum to somefile.cs, then used that new enum in someotherfile.cs, check-in somefile.cs before checking-in someotherfile.cs.  Checking in somefile.cs first will not put the source code in a state where it cannot be compiled.  You’re working on a team, anyone on the team can get the state of the project at any time, like between non-atomic file check ins.  This means they get code that doesn’t compile and they won’t know why or how to fix it–blocking them from doing their work and wasting time and impacting the project schedule.


Make use of shelving.
If what you’ve coded needs to be given to someone else to get the source code to build properly, don’t check it in in order to give it to that other person.  On cases like this, if your SCC has shelving or shelvsets, shelve the changes and inform the other person of the shelvset instead of checking in.  Let them check in the working changes as an atomic unit.  If shelving isn’t an option (consider or petition for an SCC system that does, then), send them the files for them to check in after modifications.  See next practice.


Get all current code and build before checking in.
Someone may have made changes between when you got the code you working on and when you want to check in.  If you don’t get the latest code (and potentially merge it with yours), what you check-in may leave the controlled code in a state where it cannot be built.  Get all the current code to make sure you have what will be the state of the code when you check in and that it builds first.  If your build process is long, this may require several tries.  You should address build times if this is a common problem.  Communicate to the rest of the team that you need to check in changes and that they hold off on checking in related components if necessary.


kick it on DotNetKicks.com