C# 4.0

CMAP C# 4.0 Presentation – Code Samples

Steve Michelotti — Wed, 04 Nov 2009 18:02:57 GMT

Thanks to everyone who attended my C# 4.0 New Languages Features presentation at CMAP last night. Both the code and PowerPoint are available for download.

C# 4.0 New Language Features Download

After the presentation, I had a few people ask me about some of tools I was using. They can all be found on my Developer Tools and Utilities page. To create my snippets, I’ve been using a tool called Snippy for years (link included on Developer Tools page). However, lately I’ve also been using Snippet Designer which is a Visual Studio add-in that is also quite good.

CMAP Presentations this week

Steve Michelotti — Mon, 02 Nov 2009 01:22:33 GMT

I’ll be giving a presentation on C# 4.0 New Language Features this Tuesday at the CMAP Main Meeting.

Also I’ll be presenting MVC in the Real World this Saturday at CMAP Code Camp.

Hope to see you there!

Richmond Code Camp - Code Samples

Steve Michelotti — Sun, 04 Oct 2009 20:11:26 GMT

Thanks to everyone who attended my sessions yesterday at Richmond Code Camp. Both the code and PowerPoint slides are available for download.

Download samples for: MVC in the Real World. Check out the readme.txt file in Solution Items and all SQL scripts for creating the databases.

Download samples for: C# 4.0 New Language Features.

I had several questions about some of the tools I was using during the presentations (all of which are free). For the zooming and highlighting, I was using a tool called ZoomIt. For the code snippets, I was just utilizing the built-in code snippets functionality of Visual Studio – however, I use a tool called Snippy to create all of my custom snippets. You can find links to those tools and many other tools I use on my Developer Tools and Utilities post.

C# 3.0 Deep Dish with a slice of C# 4.0 – Code Samples

Steve Michelotti — Wed, 26 Aug 2009 14:04:51 GMT

Thanks to everyone who attended my presentation last night at CapArea on C# 3.0 and C# 4.0. You can download the C# 3.0 code samples, C# 4.0 code samples, and the PowerPoint presentation from here.

Several people asked me about some of the tools I was using during the presentation. A list of the tools that I use (and more) can be found here.

Feel free to email me with any questions.

C# 3.0 Deep Dish with a slice of C# 4.0

Steve Michelotti — Sun, 23 Aug 2009 11:44:45 GMT

On Tuesday night (August 25), I will be presenting “C# 3.0 Deep Dish with a slice of C# 4.0” at CapArea .NET User Group (but I have to give Brian Noyes credit for the catchy title). The primary content of the presentation will be a deep dive into the C# 3.0 language features. The latter part of the presentation will be an overview of the features coming in C# 4.0. Hope to see you there.

Additionally, the next night (Wednesday, August 26), I’ll be at FredNUG presenting Linq to SQL.

C# 4.0 dynamic keyword with IronRuby

Steve Michelotti — Wed, 05 Aug 2009 18:51:22 GMT

In my continued exploration of C# 4.0, I wanted to put together a simple example of using the C# 4.0 “dynamic” keyword in conjunction with IronRuby. I’ve been shocked at how difficult it was to find code samples on the internet that actually do this. With much persistence (and some significant pointing in the right direction from Justin Etheredge) I got my simple example working. Given that there aren’t many great examples of calling IronRuby from C# 4.0 out there, I figured I better post the code.

First off, you need to get the *correct* version of IronRuby that will work with VS2010 Beta 1. Next, you want to add the following references to your project (all found in the “bin” folder of the IronRuby download):

IronRuby.dll
IronRuby.Libraries.dll
Microsoft.Scripting.dll

Next, create an IronRuby file called “person.rb” that has the following code:

   1:  class Person

   2:      def say_hello

   3:          puts "Hello world!"

   4:      end

   5:  end

Finally, here is the C# code:

   1:  ScriptRuntime runtime = IronRuby.Ruby.CreateRuntime();

   2:  ScriptScope scope = runtime.ExecuteFile("person.rb");

   3:  dynamic person = scope.Engine.Execute("p = Person.new");

   4:  person.say_hello();

Notice the use of the “dynamic” keyword on line 3. While a full discussion of the dynamic keyword is beyond the scope of this blog post, this keyword is the basis for the dynamic features of C# 4.0 that will be running on top of the Dynamic Language Runtime (DLR) of .NET 4.0. It will provide a unified way to interact with all things dynamic. These include:

Dynamic languages like IronRuby, IronPython, and JavaScript
Simplified .NET Reflection
COM Interop
DOM objects like HMTL and XML

I’ll be speaking at CapArea at the end of this month where the last portion of my talk will be dedicated to C# 4.0 new language features. Additionally, I’ll be devoting an entire talk to C# 4.0 at CMAP in November.

C# 4.0 Optional Parameters

Steve Michelotti — Fri, 06 Feb 2009 03:41:51 GMT

One of the new language features coming in C# 4.0 is Optional Parameters. In large part, this is due to Microsoft’s plan of co-evolution with C# and VB.NET since VB.NET has had this feature for a while. Personally, I’m still somewhat undecided about this feature and there has been much written about method overloads versus optional parameters. For example, Considerations in Overloading Procedures. Ultimately, I do think there will be some scenarios where this will be useful to make code more concise.

Consider a standard scenario with method overloading or constructor chaining. In C# we’d have several methods with different signatures where, in effect, we’re really just after default values. Let’s take the scenario where we’ve got a little helper class to send emails in our application. In some cases we want to CC the administrator to troubleshoot issues; in some cases we want rich HTML emails rather than plain text. We might set up our methods like this:

   1:  public void SendMail(string toAddress, string bodyText)

   2:  {

   3:      this.SendMail(toAddress, bodyText, true);

   4:  }

5:

   6:  public void SendMail(string toAddress, string bodyText, bool ccAdministrator)

   7:  {

   8:      this.SendMail(toAddress, bodyText, ccAdministrator, false);

   9:  }

10:

  11:  public void SendMail(string toAddress, string bodyText, bool ccAdministrator, bool isBodyHtml)

  12:  {

  13:      // Full implementation here

  14:  }

This is pretty standard method overloading and we essentially are setting default values (true for CC the Admin, and false for HTML emails). With C# 4.0 we can now make the code more concise by only having to implement 1 method:

   1:  public void SendMail(string toAddress, string bodyText, bool ccAdministrator = true, bool isBodyHtml = false)

   2:  {

   3:      // Full implementation here

   4:  }

However, you do have to take into account your scenario. If you have a situation where you actually need to know if the consuming code provided a value then this isn’t a good option because if “true” comes in for the 3rd parameter, you don’t know if the consuming code actually set this explicitly or if it was simply the result of the default value. But in typical scenarios like this, it’s not a big deal. Cracking open Reflector and looking at the IL that the C# compiler is generating:

   1:  .method public hidebysig instance void SendMail(string toAddress, string bodyText, [opt] bool ccAdministrator, [opt] bool isBodyHtml) cil managed

   2:  {

   3:      .param [3] = bool(true)

   4:      .param [4] = bool(false)

   5:      .maxstack 8

   6:      L_0000: nop

   7:      L_0001: ret

   8:  }

Which Reflectors translates to a C# equivalent of:

   1:  public void SendMail(string toAddress, string bodyText, [Optional, DefaultParameterValue(true)] bool ccAdministrator, [Optional, DefaultParameterValue(false)] bool isBodyHtml)

   2:  {

   3:  }

So if consuming code is written using the least specified “overload” like this:

   1:  email.SendMail("bob@foo.com", "Hello World");

The IL that the C# compiler will generate will actually be the equivalent of this:

   1:  email.SendMail("bob@foo.com", "Hello World", true, false);

What’s more interesting is that, unlike traditional method overloading, you have the ability to omit only the 3rd parameter in conjunction with the new Named Parameters language feature and write your code like this:

   1:  email.SendMail("bob@foo.com", "Hello World", isBodyHtml: true);

This will allow consuming code to only pass 3 arguments for succinctness but still invoke the appropriate overload since the IL generated in that instance will be equivalent to this:

   1:  email.SendMail("bob@foo.com", "Hello World", true, true);

Overall, it’s by no means an earth shattering feature that is being added to the language in stand-alone scenarios (though it will be have a *much* bigger impact in COM Interop). Used in the correct scenarios, it can improve your code.

C# 4.0 Named Parameters for better code quality

Steve Michelotti — Fri, 23 Jan 2009 02:51:04 GMT

Sometimes new features are added to a language which fundamentally change how we do things (e.g., when generics was added to .NET 2.0). However, there are other times when features are added to the language that are “syntax sugar” or “nice to have’s”. My outlook on those items has always been that “syntax sugar” is typically a good thing – if there is some feature that allows the code to be more expressive/readable then that is a great thing. Sure, the IL might not be any different behind the scenes but you want your code to be as understandable as possible and developers that come behind you can easily understand what your intent was.

To that end, I believe that named parameters being added to C# 4.0 is a good thing. I’m certainly not advocating that named parameters be used for every method call but there are several instances where this is going to be helpful in terms of code readabilty. Often you see argument passed to a method and you have no idea what the parameters are for. Brad Abrams has a nice design guidelines post regarding Enums vs bool arguments which talks about this very thing. He discusses that enums are often a better choice than Boolean for method parameters because they express intent more clearly. So in the case where you can’t control the method you are already calling, you can use named parameters to better express intent.

Consider this line of code:

   1:  File.Copy("source.txt", "destination.txt", true);

Unless you’re a developer that is already familiar with this method, you can only guess as to what the last Boolean parameter is for. With C# 4.0 named parameters this code can be written like this to more clearly express intent:

   1:  File.Copy("source.txt", "destination.txt", overwrite: true);

Object initializers, while typically used in the context of LINQ, can also be used as a stand-alone language feature to express intent more clearly. For example, this snippet of code:

   1:  Person person = new Person();

   2:  person.FirstName = "John";

   3:  person.LastName = "Smith";

   4:  person.DateOfBirth = new DateTime(1970, 1, 1);

can be re-written with object initializers like this to be more concise and better express intent:

   1:  Person person = new Person() { FirstName = "John", LastName="Smith", DateOfBirth = new DateTime(1970, 1, 1)};

It’s as if you can use constructor like syntax to initialize the object – but it’s *more* readable than a constructor because the object initializer uses the property names so it’s obvious what is happening and what properties are being assigned to. Of course, you can only use that type of syntax in C# 3.0 IF all three of those properties have publicly accessible setters. What happens if you actually do have a constructor definition that looks like this:

   1:  public Person(string firstName, string lastName, DateTime dateOfBirth)

In that case, you have no other option in C# 3.0 other than to invoke the constructor like this:

   1:  Person person = new Person("John", "Smith", new DateTime(1970, 1, 1));

So it’s not 100% obvious what is being assigned in the constructor (e.g., that third DateTime parameter might be date of birth, might be date hired, who knows). In C# 4.0, you can invoke the constructor like this:

   1:  Person person = new Person(firstName: "John", lastName: "Smith", dateOfBirth: new DateTime(1970, 1, 1));

This expresses intent clearly and makes the code more understandable. Again, named parameters should not be used gratuitously but there are many instances where it can make your code higher quality.