Visual Studio 2008 has lots of goodies in it, like LINQ syntax, CSS editing, and testing tools. There’s a lesser-known feature which I really appreciate though – the “Remove and Sort Usings” command in the C# editor.

You activate the command by placing your cursor over the using statements and clicking on the right mouse-button.

Using this groovy tool, I’ve been able to go through my old ugly C# files and get rid of all the superfluous using statements, then tidy them up, all at the click of a button. It’s something I always wanted to do, but had no time for, and didn’t want to pay for an extra tool to do it for me.

The only problem with the feature is that you have to go through every file and right-click on the “using” statements to tidy them up. That can get a bit tedious, but it’s worth it.

But now it’s the Visual Studio Extensibility Team to the rescue!

The VSX team at Microsoft have just released PowerCommands for Visual Studio 2008. It’s a free tool for Visual Studio with loads of new tools for making a VS-developer’s life easier. And one of those new tools is a Remove and Sort Usings command at the project level.

You activate it with a right-click on the project itself.

The tool then does the same Remove and Sort command for every file in the project.

Tip: Make sure your project is buildable before using the tool. If there is an error stopping the build from running, you will get dialogs asking you to confirm every change in every file.

PowerCommands for Visual Studio 2008 also contains commands for:

• Collapse Projects
• Copy Class
• Paste Class
• Copy References
• Paste References
• Copy As Project Reference
• Edit Project File
• Open Containing Folder
• Open Command Prompt
• Unload Projects
• Reload Projects
• Remove and Sort Usings
• Extract Constant
• Clear Recent File List
• Clear Recent Project List
• Transform Templates
• Close All

So, where can you get the tool?

The official site for PowerCommands is at the Visual Studio Gallery, but when you get there, you won’t see a download button. You actually have to click the “Learn More” button to go to the download page at the MSDN code gallery.

You can read more about PowerCommands on the Visual Studio Team Extensibility blog.

I was recently reading Programming Ruby: The Pragmatic Programmers’ Guide, Second Edition, and came across this piece of example Ruby code:

[1,3,5,7].inject(0) {|sum, element| sum+element} -> 16
[1,3,5,7].inject(1) {|product, element| product*element} -> 105

Inject is a method which acts on an array by aggregating or accumulating the values within that array. It loops through the array, and for every item in the array, it performs a function. It then saves the result for the next iteration of the loop and eventually returns the aggregated value.

In C# 1.0 you would probably write such a method like this:

int sum = 0;
int[] list = new int[] { 1, 3, 5, 7 };
foreach (int item in list)
{
  // Perform some function, then save the result
  sum = sum + item;
}

It’s a bit long-winded, and if you wanted to make it reusable, you’d have a hard time.

In C# 3.0, you can do it just like you can in Ruby.

Defining the Aggregation

First, let me explain how the Ruby inject method works.

First of all, it’s really misnamed in Ruby. The method is an aggregator, or even an "accumulator". It aggregates or accumulates values. It takes two parameters – a starter value, and a block. In C# 3.0 we basically call a block a delegate, although in this case, it’s more like a Lambda Expression.

The inject method works like this:

1. it takes the starter parameter and sets the aggregated value (the sum in the above example) to its value.
2. For the first item in the array, it passes the tarter value and the item itself to the block, which then performs the defined function on it.
3. The return value from the block is then assigned to the running aggregated value.
4. The running aggregated value is passed into the next iteration with the next item from the list. The function is called on those items again.
5. When the method has iterated over all items in the list, it returns the aggregated value.

Moving to C# 2.0

So, let’s imagine you were trying to write the Inject method in C# 2.0. If you were to refactor the above C# 1.0 example as C# 2.0, you might use anonymous methods to write this:

// Define a delegate
delegate int Aggregator(int sum, int item);

static void Main(string[] args) {

  int sum = 0;
  int[] list = new int[] { 1, 3, 5, 7 };

  sum = Inject(sum, list,     delegate(int starterVal, int item) {
      return starterVal + item;
    });
}

int Inject(int starterVal, int[] list,
           Aggregator aggregator) {
  int sum = starterVal;
  foreach (int item in list) {
    // Perform some function, then save the result
    sum = aggregator(sum, item);
  }
  return sum;

However, that would only work for int objects. You could really make it generic, and use the same method for other types:

// Define a delegate
delegate T Aggregator<T>(T sum, T item);

...

  sum = Inject<int>(sum, list,
     delegate(int starterVal, int item) {
      return starterVal + item;
    });

...

T Inject<T>(T starterVal, T[] list,
  Aggregator<T> aggregator) {
  T sum = starterVal;
  foreach (T item in list) {
    // Perform some function, then save the result
    sum = aggregator(sum, item);
  }
  return sum;
}

It’s nicer, but the Ruby method still wins hands-down for neatness.

Move Over Ruby, Here Comes C# 3.0

The good news is, the C# 3.0 compiler and the .Net 3.5 framework can now take care of most of this for you.

To start with, the Aggregator delegate is no longer necessary, because the new Func<T,T,T> delegate already defines a generic delegate which returns a value.

T Inject<T>(T starterVal, T[] list, Func<T,T,T> aggregator)

Secondly, the anonymous function using the delegate keyword can be replaced by a lambda expression like this:

(starterVal, item) => starterVal + item

Thirdly, the Inject method can be defined as an extension method so that you can call it like this:

sum = list.Inject(sum, (starterVal, item) => starterVal + item );

And fourthly, the compiler can infer the type for you, so you don’t need to specify it on calling the method.

The Aggregate Method

But the even better news is that this method is already defined in the .Net framework for you, so you don’t even have to write it. Instead of being called inject, it’s called Aggregate, and is defined on the System.Linq.Enumerable<T> class.

So basically, using C# 3.0, you could reduce the above code to this:

var sum = 0;
var list = new[] { 1, 3, 5, 7 };
sum = list.Aggregate(sum,
                     (starterVal, item) => starterVal + item );

You get an extra bonus point if you spotted the extra C# 3.0 features I sneaked in there – the var keyword, and array initializers.

C# 3.0 is pretty neat huh? Move over Ruby.

Dude! I got quoted! And by none other than Rob Conery of SubSonic fame.

It seems like my last post caused quite an unexpected stir. Thanks to both Rob and Scott for taking the time to answer me. I really appreciate it.

A Word of Appreciation

Let’s get something in perspective. Rob has actually produced something of immense value with SubSonic. I have just complained about it. Rob could very easily have just hammered me down, but he didn’t. Thanks, Rob.

Scott too.

In the last episode of his most excellent podcast, Scott said to his Dad that he likes to stir things up. “Presenting options” was the phrase I think he used. In that case, we are two peas in a pod. I always like to ask questions. If my question uncovers an unjustified assumption, things usually get better. If I’m wrong, then at least I come out knowing why I was wrong and understand the problem better.

While studying for my physics degree, I was asked to give feedback for a course on “Cosmic Dust”. I commented that it was just a completely pointless course. I mean, why waste 12 weeks of lectures studying the invisible dust floating around in space? Instead of numbing our brains with such useless information, we could have been learning something much more relevant. That particular comment, although made privately, really stirred up the lecturer. He got quite mad actually. He even wrote a long letter to the students with his reasoning for why cosmic dust was so important. That itself was unprecedented. No lecturer had ever given us feedback to our feedback before.

Not much changed in the end, but at least I came out of it understanding more about what I’d been doing. Maybe that will happen with ASP.Net MVC.

So thanks to both of you for taking me seriously.

How Dare They!

Last month I watched a documentary about J.K. Rowling. It followed her as she completed and published the 7th and final Harry Potter book. It was the fasting selling book of all time. Truly amazing. But what amazed me most about the whole documentary was a comment made by two girls who had been queuing all night to get their copy of the book:

“Finally! We’ve been waiting 10 years for this!”

The remark was made with a tinge of disgust. It was as if the author had no right to take such a long time writing the book. How dare Mrs Rowling take so much time to finish her book while they had to suffer while sitting around waiting for it. How inconvenient for them! How inconsiderate of Mrs Rowling!

I thought, “if you wanted the book so much, why didn’t you write your own?”

In that spirit, I’m going to try to do something about the ASP.Net MVC thing myself. I don’t want to be that kind of person that complains but does nothing.

Wait! There’s a baby in that bath-water!

I read Rob’s readers’ comments, and I think that it doesn’t require a full rewrite of ASP.Net to do what they want. In fact, I already wrote a bit of code, modeled loosely on Django templates, which allows an ASP.Net developer to control the page output pretty much the same way as MVC promises to do. I’ll have to dig the code out of its hiding place, but then I plan to integrate it with a small Model-View-Presenter framework (a couple of generic base-classes for a Page and Presenter) which will enable a much better way for writing pages than the normal ASP.Net pages do. It also allows full testing of the controlling code.

And better yet, the MVP stuff is based on a refactored and simplified version of some Patterns and Practices code. (Yaaay, we can all be happy together!)

I’ve used this pattern, and each Presenter class is usually a few lines long. My ASP.Net page only contains presentation logic, i.e. stuff to render the page and retrieve input. I don’t need a controller nor a completely new framework to do it. In fact, a Controller class would be much worse, IMHO, because Controllers contain the code for more than one concern – a list page, an edit page, a delete page, etc. (I think that those things could be pragmatically abstracted and made easier anyhow, but that’s another story.) I personally prefer to keep my concerns separate.

And I’m not the only one who likes MVP. Craig Shoemaker does too.

So here’s my plan: I’ll try to publish some ideas and persuade you all to use them. Then I’ll get Microsoft to take Routes, Controllers, and whatever other goodies they’ve got in ASP.Net MVC, and put them in the next full-blown version of ASP.Net. Then everyone can use them and we can carry on with life as normal. I won’t have to use UrlRewriter to do my Routing any more and Microsoft can go back and finish off Workflow Foundation, ASP.Net Ajax, and Patterns and Practices.

Well, that’s the plan, anyway.

(I’ve just got to tidy up some of my code before I publish it. Give me a moment…)

Scott Hanselman just posted his latest article in his weekly source code series. He shows various ways of producing the Fibonacci Sequence using various languages. I found it really interesting, for two reasons:

1. I tried to do the C#3.0 one on my own after listening to a podcast about F#, and never could work it out. (Doh!)
2. It makes me question what I thought about coding.

You see, I spend a lot of time refactoring. Sometimes too much. I have to ask myself why. It’s usually so that I can come back to the code later, and still understand what I was trying to do. Most of the time, conciser is better. But not always!

And that’s what I see in this post.

Suppose I had written this C# function (shamelessly stolen from Scott’s post):

Func<int, int> fib = null;
fib = n => n > 1 ? fib(n - 1) + fib(n - 2) : n;

Compare this to the C# 2.0 version:

static int Fibonacci(int x) {
  if (x <= 1)
    return 1;
  return Fibonacci(x - 1) + Fibonacci(x - 2);
}

Apart from the fact that these methods actually give different answers (sorry, Scott), if I were to try to understand these methods 6 months after writing them, which one of the code samples would I be most glad of seeing again?

You see, most code only gets read again for two reasons:

1. to debug it, or
2. to hand it over to someone else

In both cases, clever though it may seem, the first conciser version would probably cause more trouble. Now, don’t get me wrong, I’m all for good concise code, but XSLT is concise, and I hate debugging that.

Now, considering that in order to reuse the Func<int, int> function, I would have to pass the around, thus holding it in a static variable, or wrapping it in another class, it doesn’t actually turn out to be that practical after all. Concise, yes. Practical and readable, hmm.

So, while we have a very-much-by-Ruby-On-Rails-driven trend going to make code as beautiful as possible, don’t forget to not go too far. We have to be able to read code later on, remember.

One of the biggest questions with Anonymous Types is “can I pass them around?” If not, why not? Can you do something like this, for example:

var GetAnonymousValue() {
  return new { Name = "Richard Bushnell" };
}

void Main() {
  var value = GetAnonymousValue();
  var name = value.Name;}

The answer is simple: no, you can’t pass anonymous types across functions. var is not a dynamic variable, like in JavaScript. The CLR knows nothing about “var”, as the compiler just uses it to infer types when a variable is initialized.

At least, that was the answer until now. Using a simple extension method and generics, Alex James just showed a nice way to pass them around on his blog.

The trick is to use an example of the anonymous type you expect.

object GetAnonymousValue() {
  return new { Name = "Richard Bushnell" };
}

void Main() {
  var value = GetAnonymousValue().CastByExample(new { Name = "" });
  var name = value.Name;
}

While this might be a little dangerous, especially if you’re not testing your code regularly, this could be the solution to a few problems I can already think of.

Watch out for casting exceptions at runtime though! If you make a mistake anywhere, you’ll won’t get a compile-time exception, but a nasty runtime exception instead.

Name

Use Automatic Property

Summary

You have a property in a class which just wraps a field of the same type, and simply returns or sets that field.

private string _field1;
public string Field1
{
  get { return _field1; }
  set { _field1 = value; }
}

Becomes:

public string Field1 { get; set; }

C# Version

3.0

Motivation

Encapsulation is quite possibly the key principle of object-oriented design. It is common practice in C# to encapsulate fields by wrapping them in a property.

When a class has many properties, much of the class is taken up by the same coding pattern for a property:

private string _field1;
public string Field1
{
  get { return _field1; }
  set { _field1 = value; }
}

In C# 3.0 this block of code can be removed by using automatic properties. The compiler will do the same thing that you would have done before if you just define the property name and the getter and setter.

public string Field1 { get; set; }

Reducing the property code like this makes it much easier to understand the code later, as only the necessary details are defined. Even if you use a terse syntax formatting, as in the previous example, you are saving 5 lines of code per property. The way I usually format my code with extra linefeeds, I save 9 lines for each one. When there are a lot of properties in a class, that is a large amount of code which can be removed.

Removing code isn’t just good for making it easier to understand; it makes it easier to test too. You wouldn’t have to test properties to see if they are simply setting and getting the correct values with this syntax, as the compiler is doing the work for you. So if you have unit tests, you might be able to remove lots of property testing code.

Of course, if the property does not just simply set or get a field value, you must use the previous C# 1.0 syntax for properties. In addition, you cannot specify get or set alone, but you can include scope identifiers to make a set private, for example:

// The following are not valid:
// Automatically implemented properties must define both get and set accessors
public string GetOnly { get; } // Not valid
public string SetOnly { set; } // Not valid either

// But this is okay
public string GetWithPrivateSet { get; private set; }

Mechanics

• Remove the body of the property, replacing the code between the get and set blocks with a semicolon “;” .
• Compile.
• If there is a compiler warning that the field is no longer being used, you can now simply remove the field which the property was wrapping.
• If there is no compiler warning, other methods or properties are using the field directly. You can remove the field and recompile anyway, which will give you the location in the code where the field is being used. Replace each reference with a reference to the property instead.
• Compile.

Repeat for each property.

If the field was a protected field, not private, then you might have subclasses which access the field. They will have to be changed to access the property instead of directly accessing the field.

Tip: For new code, you can simply use the code snippet “prop” in Visual Studio 2008 to get an automatic property.

Examples

I’ll just do an example with one property, even though it looks a lot better with a longer class.

class Account
{
  private long _id;
  public long ID
  {
    get { return _id; }
    set { _id = value; }
  }
}

First, remove the body of the property getter and setter (and apply a bit of reformatting too, if you like):

class Account
{
  private long _id;
  public long ID { get ; set ; }
}

Compile, to make sure the code is happy, then remove the field:

class Account
{
  public long ID { get ; set ; }
}

My last post gave a simple idea of how to do a Mixin with C#. Rather than repeating what someone else has already done, if you want to see a more complex example of what can be done, check out Create Mixins with Interfaces and Extension Methods by Bill Wagner at MSDN.com.

I really like Scott Hanselmann’s idea to write an indefinite series of posts about reading code to be a better developer. I’m going to copy his idea, and write a series of my own.

Since its first version, C# has evolved from being a Java clone to something much more dynamic. I’ve noticed that developers often find themselves stuck long projects, and its sometimes hard to keep up with all the changes. I know a lot of developers who are still using .Net 1.1 because the project they are working on forces them too. For them, C# is still very much like Java.

So for all those who want to know what has changed since the first version, I’ve decided to make a new series of posts called “Refactoring from C# 1.0 to C# 3.0″. I will show through examples how you can make your code easier to understand and maintain by using the new features in C#. I’m not necessarily going to do it in historical order – I won’t show any preference for C# 2.0 Generics over C# 3.0 Extension Methods, for example. And C# 2.0 anonymous methods will take second place to C# 3.0 lambda expressions, which generally replaces them. I’m going to try to show how things have changed, and when you should or should not use the new features.

Some of the things I’ll cover are:

• Anonymous types
• Anonymous methods and lambda expressions
• Extension Methods
• Yield statements and iterators
• Generics
• List comprehensions (ala LINQ)
• Mixins
• Partial types
• Type and Array inference
• Property visibility
• Automatic properties
• Static classes
• The Global namespace
• Object, Collection and Dictionary initializers

I’ll try to treat each one as a refactoring opportunity, and not as a “must” or “must-not”. The idea is to write more maintainable code using the new features, not just go along with the trends.

Note: I’m not going to treat the .Net base library at all. Just the C# language.