Peter Hallam's WebLog

Peterhal - Last day at Microsoft

I've been promising myself an extended vacation for a long time now, but working at Microsoft has been so much fun I've kept postponing it. Well, this is it - my last day at Microsoft.

Feel free to email me at 'hotweird' at hotmail.

What Makes a Good Programmer?

I just read two salon articles about Scott Rosenberg's new book Dreaming in Code. His thesis is that "programing is hard" and uses the experiences of the development of the Chandler project to frame the discussion. Scott identifies a common problem in large software development - inconsistent terminology use across the software development team. At the same time he complements the members of the development team as being talented programmers. These two ideas struck me as incongruous. How can a bunch of "ace programmers" end up with such a basic problem? Should programmers encountering this problem really be deserving of the accolade "ace"? And what skills would I expect from an "ace" programmer anyhow?

Before I go any further, I want to make it clear that I don't want to talk down Scottt or the Chandler team. Scott makes a number of great points that reflect my own experiences. Virtually every large software project I've seen has had problems akin to those Scott describes. Especially every large project I've worked on. I'm certainly as guilty of these difficulties as any programmer. But the examples that Scott describes are good grist for discussion about software development.

When people talk about talented programmers they are usually refering to their ability to write correct code, whch solves problems quickly and elegantly. I suspect that that is what Scott was implying by describing the Chandler team as ace programmers. Raw coding skills vary widely across individuals. When it comes down to it some programmers are just more talented than others at writing code. Large team projects - projects with more than 3 programers with schedules of more than a few months - require a whole set of skills beyond raw coding. On large teams, excellent coding skills are a prerequisite. Alone, they qualify you as a beginner, not an ace.

From Beginner to Good

For me, the mark of a good team programmer is someone who does not suggest rewriting everything from scratch. Scott makes the very valid point that programmers like to program - and that they don't like to understand code written by others. Truer words were never spoken. Time and time again I've seen smart novice programmers suggest rewriting code produced by other programmers. I've noticed an inverse relationship betwen the esteem I hold for a programmer and the number of times I've heard them suggest a rewrite of a large software project.

Good team programers are capable and willing to work with a codebase that is too large for a single person to rewrite within the project's schedule. They recognize that the existing codebase has shortcomings and they have the maturity and discipline to know that attempting to 'fix' everyone of those shortcomings will almost certainly kill the project. Instead they identify those areas which must be improved on to deliver the project, and they have the skills to make significant changes to a large and ugly (because every large piece of software is ugly - but that's another story) codebase without causing the whole thing to destabilize.

And From Good To Great

If the mark of a good team programmer is the ability to work (usually grudgingly) with the code of others, then the mark of a great team programer is the ability to produce code that other programmers on the team will gladly use. Programmers are the most fickle sort, and if you can produce code that other, less skilled, coders will use without suggesting a rewrite - then you've elevated yourself to the top of the programing heap. Great programmers produce code that is so good that it will prevent the cross programer problems that plague most large software projects.

Code Review: Double Checked Locking Code

New F# Release.

Don Syme and the F# team have just released a new version of F#. Check it out here: http://blogs.msdn.com/dsyme/archive/2006/11/30/f-1-1-13-now-available.aspx

Peter

What Do Programmers Really Do Anyway? The data is in!

The smart folks over in the MSR-Human Interactions in Programming team have done some interesting research into the question of "What Do Programmers Really Do Anyway?". I'm more than a little pleased to see that the data is consistent with the assertions I made in my previous blog posts.

Some of their results are here:

http://research.microsoft.com/research/pubs/view.aspx?type=Technical%20Report&id=994

http://research.microsoft.com/hip/papers/Ko2007BugFixing.pdf

http://research.microsoft.com/hip/

I'm looking forward to more great work from these folks,

Peter

C# Automatically Implemented Properties - My Video Debut

Hey Folks,

Charlie Calvert video taped our discussion on some of the new C# 3.0 features. Find it here: http://wm.microsoft.com/ms/msdn/visualcsharp/peter_hallam_2006_11/PeterHallam01.wmv.

Cheers,

Peter

What Do Programmers Really Do Anyway? (aka Part 2 of the Yardstick saga)

What do professional programmers really do with their time anyway?

Design Code

Write New Code

Understand Existing Code

Modify Existing Code

Verify Existing Code Still Works

New Code:                         2%

Modifying Existing Code:     20%

Understanding Code:         78%

New Code:                         5%

Modifying Existing Code:     25%

Understanding Code:         70%

C# Stumper: Why does this code not compile?

Hey folks,

First off, I want to appologize for not having any activity on my blog for a while. I just got back from a wonderful 3 week vacation in Spain. Now that I'm back, rested and limber, here's a twisted peice of C# code which is gauranteed to turn your brain inside out.

Why does the compiler (correctly) give an error message on the override in the following code?

abstract class A<T>
{
    public abstract T getT();

    class B : A<B>
    {
        public override B getT()
        {
            throw new System.Exception("The method or operation is not implemented.");
        }
    }
}

I got this code from a coworker, and I must confess that the first time I saw it I was convinced that the behaviour was a compiler bug. It turns out that the compiler correctly diagnoses the problem, though even after seeing the error message it took me a while to figure out what's going on. I'll post a discussion in a couple of days.

Any Takers?

Peter
C# Guy

Many C# Questions: Switching on non-constant values.

I finally decided to play with the style settings on my blog. As you may have guessed, I'm a bit of a newbie when it comes to websites and blogging. Let me know what you think of the new look. Last weeks posting generated some great comments. Tzagotta asks:

Why are constant expressions required in case labels? I see a switch statement conceptually the same as a series of chained ifs/else ifs.

This is an interesting question. It seems reasonable that you should be able to switch on an expression of any type, and have case labels which can take any value – even values which are not compile time constants. A simple example would look something like this:

class Program {

    static void Main() {

        object myFirstObject = ...;

        object mySecondObject = ...;

        object obj = ...;

        switch (obj) {

        case myFirstObject:  ...; break;

        case mySecondObject: ...; break;

        default:             ...; break;

        }

    }

}

which would be equivalent to this code:

class Program {

    static void Main() {

        object myFirstObject = ...;

        object mySecondObject = ...;

        object obj = ...;

        if  (obj == myFirstObject) {

           ...

        } else if (obj == mySecondObject) {

           ...

        } else {

           ...

        }

    }

}

At first glance this seems like a great idea – the switch is slightly more compact and readable than the chained ifs, both desirable characteristics of a programing language. If the construct could easily be limited to this simple example it might be a reasonable language extension to consider. Unfortunately, things are not as simple as they appear at first glance…

Firstly, what happens when myFirstObject is equal to mySecondObject? Well that depends on which case label came first in your switch. The order of the case labels becomes significant in determining which block of code gets executed. Because the case label expressions are not constant the compiler cannot verify that the values of the case labels are distinct, so this is a possibility which must be catered to. This runs counter to most programmers’ intuition about the switch statement in a couple of ways. Most programmers would be surprised to learn that changing the order of their case blocks changed the meaning of their program. To turn it around, it would be surprising if the expression being switched on was equal to an expression in a case label, but control didn’t go to that label.

Secondly, allowing non-constant expressions as case labels lets in some significantly less desirable code as well. For example, this code would also be legal:

        switch (obj) {

        case myFirstObject:  ...; break;

        case mySecondObject: ...; break;

        case EraseMyHardDrive(): ...; break;

        default:             ...; break;

        }

In C#, any non-constant expression can yield side effects. There is currently no notion of a non-constant expression which does not have side effects in C#. Seeing code like this will leave the reader scratching their head wondering when their hard drive will get erased.

And lastly, programmers coming from a C/C++ background will expect that the execution of a switch statement will be fast and that it will take about the same time to reach any particular case label. When the case labels are constant integral values (or strings), the compiler can do some great optimizations to make the execution speed of the construct match the coder’s expectation. With non-constant case labels, getting to the 100^th case label would take significantly more time than getting to the 10^th case label. Again, this would be surprising to the programmer.

Peter

C# Guy

Many Questions: Switch On Enum

Just a quick one this week: 

Why is it that you cannot use enum constants in a switch statement's cases without first casting them to type int?

Often you will want to use Enum constants as case labels in switch statements. Sometimes, the compiler will complain and require a cast to int on each case label. This will look something like this:

    enum Color { Red, Green, Blue };

    int i = ...;

    switch (i)

    {

    // cast required! Aarg!

    case (int)Color.Red:    break;

    case (int)Color.Green:  break;

    case (int)Color.Blue:   break;

    }

The confusion stems from a subtle difference between C++ and C#. In C++, values of enum type are implicitly convertible to int. In C#, conversions between an enum type and its underlying type are explicit and require a cast. To maintain consistency, the requirement for the cast carries over into the use of enums in switch statements.

However, you can use expressions of enum type as case labels without a cast, but only in a type safe way. The rule is that the type of the expression being switched on, the ‘governing type’ of the switch statement in C# language spec terminology, must match the type of the expressions in the case labels.

For example:

    enum Color { Red, Green, Blue };

    Color c = ...;

    switch (c) // Governing type is ‘Color’ not ‘int’ so ...

    {

    // ... no cast required

    case Color.Red:    break;

    case Color.Green:  break;

    case Color.Blue:   break;

    }

One of the design goals for enums in C# was to treat them as first class types that were truly distinct from their underlying type. This is one of the subtle ways that this decision manifests itself in the language.

Peter

C# Guy

Many Questions: Generics Variance

One of the main benefits of the addition of generics to C# is the ability to easily create strongly typed collections using types in the System.Collections.Generics namespace. For example, you can create a variable of type List<int>, and the compiler will check all accesses to the variable – ensuring that only ints are added to the collection. This is a big usability improvement over the untyped collections available in version 1 of C#.

Unfortunately, strongly typed collections have drawbacks of their own. For example, suppose you have a strongly typed List<object> and you want to append all the elements from a List<int> to your List<object>. You would like to be able to write code like this:

            List<int> ints = new List<int>();

            ints.Add(1);

            ints.Add(10);

            ints.Add(42);

            List<object> objects = new List<object>();

            // doesn’t compile ‘ints’ is not a IEnumerable<object>

            objects.AddRange(ints);

In this case, you would like to treat a List<int> which is also an IEnumerable<int>, as an IEnumerable<object>. This seems like a reasonable thing to do – as int is convertible to object. It is very similar to being able to treat a string[] as an object[] as you can do today. If you find yourself in this situation, the feature you are looking for is called generics variance – treating an instantiation of a generic type (in this case IEnumerable<int>) as a different instantiation of that same type(in this case IEnumerable<object>).

C# doesn’t support variance for generic types, so when encountering cases like this you will need to find a workaround in your code. If you do encounter this kind of problem, there are a couple of techniques you can use to workaround the problem. For the simplest cases, like the case of a single method like AddRange in the example above, you can declare a simple helper method to do the conversion for you. For example, you could write this method:

    // Simple workaround for single method

    // Variance in one direction only

    public static void Add<S, D>(List<S> source, List<D> destination)

        where S : D

    {

        foreach (S sourceElement in source)

            destination.Add(sourceElement);

    }

    ...

    // does compile

    Add<int, object>(ints, objects);

This example shows the some characteristics of a simple variance workaround. The helper method takes 2 type parameters, for the source and destination, and the source type parameter S has a constraint which is the destination type parameter D. This means that the List<> being read from must contain elements which are convertible to the element type of the List<> being inserted into. This allows the compiler to enforce that int is convertible to object. Constraining a type parameter to derive from another type parameter is called a ‘naked type parameter constraint’.

Defining a single method to workaround variance problems is not too bad. Unfortunately variance issues can become quite complex quite quickly. The next level of complexity is when you want to treat an interface of one instantiation as an interface of another instantiation. For example, you have an IEnumerable<int>, and you want to pass it to a method which only takes an IEnumerable<object>. Again, this makes some sense because you can think of an IEnumerable<object> as a sequence of objects, and an IEnumerable<int> is a sequence of ints. Since ints are objects, a sequence of ints should be treatable as a sequence of objects. For example:

        static void PrintObjects(IEnumerable<object> objects)

        {

            foreach (object o in objects)