11/29/07

Please use File.ReadAllText and the like

Starting from .NET 2.0 the basic file read/write API is finally implemented how it should be. I noticed that some people are still using the old way (StreamReader & Co) so I highly recommend the static methods

  • ReadAllText
  • ReadAllLines
  • ReadAllBytes

and

  • WriteAllText
  • WriteAllLines
  • WriteAllBytes

on the System.IO.File class.

Thanks :)


Update: I'd like to correct myself. Thanks to kerneltrap (see comments below) I'm not suggesting people should always use File.ReadAll* as opposed to the stream based approach, but this makes a lot of sense for simple and small files you'd normally read in one step, for the code readability reasons.

Of course, if you are doing non-trivial file operations, using using+StreamReader/Writer is better for performance reasons, and you don't have to load the entire file in memory this way. I was just seeing some cases where it was needed to read a small (10 KB) file into a string, and StreamReader.ReadToEnd was used for this purpose. So I'm sorry for not clearly expressing what I actually meant :)



kick it on DotNetKicks.com

11/27/07

Extension methods: one of my favorite C# 3.0 features

With C# 2.0 I sometimes had a feeling that something bigger is coming. As it now turns out, it was C# 3.0 (surprise!). Now the whole picture makes perfect sense, all the features start playing together seamlessly and I have to say that it is an awesome release. LINQ is a fundamental breakthrough and all the machinery that was required to implement it is great as well. I especially like extension methods, because they allow me to write more concise and expressive code than earlier.


Enhancing existing APIs


Before C# 3.0, the creator of an API or a framework was solely responsible for the readability and the usability of the API. Users of the API had to consume available methods as they were, unless they were ready to build own facades, adapters or decorators. Now the clients of an existing API can significantly enhance its readability, expressiveness and usability without even changing a single bit about it.


Addind default implementation to interfaces


Another advantage is similar to type classes in Haskell - ability to add some default implementation to existing interfaces. The best example for this is IEnumerable<T>, which now boasts so much more functionality than earlier! And note: we haven't changed a thing about IEnumerable<T>, we just added some stuff somewhere else, and all IEnumerable<T> implementations suddenly became so much more powerful. As we know from my previous posts, this is like adding 'mixins' to the language - just implement the interface, and you get this default functionality for free.


Composability and fluent interface


Also, an important advantage of extension methods is that they can be called on null objects without any NullReferenceExceptions. The best example for this is of course the string.IsEmpty() method:


        public static bool IsEmpty(this string possiblyNullString)
{
return string.IsNullOrEmpty(possiblyNullString);
}


This simply boosts composability because we don't have to check for null before actually calling a method on an object - we can do it inside the extension method. Earlier, callers were responsible to check for a null object every darn time they wanted to call an instance method on that object. Now, if we can gracefully handle a null object without throwing (e.g. just return null), it saves so much effort on the caller's side. As I said, our calls become truly composable, for example, I can chain calls to Object1.Method2().GetObject3().TryAndGetObject4().OhAndPerhapsTryGettingObject5AsWell() without worrying that one of the methods might return null. If it does return null, the whole chain won't throw and will just return null. Of course, there can be a lot of pain debugging this thing because we don't save intermediate results, but this is still a huge enabler for People Who Know What They Are Doing. This composability is a also a nice helpful feature for designing Fluent API (speaking of fluent API... what about extension properties??)



Extension methods in action: populating and grouping TreeView items



Now let me show a couple of delicious examples. I had an interesting problem recently. There was a list of objects (say Cars), each of the objects had four properties. Let's say like this:


    class Car
{
public string Make { get; set; }
public string Model { get; set; }
public int Year { get; set; }
public Color Color { get; set; }
}

Now, I had to add all Cars from the list to a WPF TreeView control, and hierarchically group cars by Make (similar makes go under a single node), then by Model, then by Year, and finally by Color. This is actually a pretty good interview question, and as I usually totally suck at interview questions, I started building an overly complicated strongly typed object model to represent a MakeGroup (based on Dictionary), which contains a ModelGroup, which contains a YearGroup etc. etc. I would then use LINQ to query over the master car list, group by make, for each group create a MakeGroup object, etc. etc. After building the object model was done, I would walk it with a special TreeViewItemBuilder that would build the treeview items and nest them correspondingly. After about 1,5 hours of this mess (unfortunately, interviews usually last less than 1,5 hours) I got struck by a what I think is an excellent idea. I wrote this extension method:


    public static class WPFExtensions
{
public static TreeViewItem FindOrAdd(
this ItemsControl parent,
string header)
{
// try to find an existing item with this name
TreeViewItem result =
parent.Items.Cast<TreeViewItem>()
.FirstOrDefault(x => x.Header.ToString() == header);

// if not yet there, don't throw, just create it in place
if (result == null)
{
result = new TreeViewItem { Header = header };
parent.Items.Add(result);
}

// and return
return result;
}
}

Now, I threw away my overly engineered "solution" and came up with this instead:


            foreach (Car car in GetCars())
{
treeView1
.FindOrAdd(car.Make)
.FindOrAdd(car.Model)
.FindOrAdd(car.Year.ToString())
.Items.Add(new TreeViewItem { Header = car.ToString() });
}

These are 8 lines instead of 200+ I wrote first. This is much more manageable and flexible than my original solution - you can easily change the code to e.g. first group by Model, then by Name - by swapping two lines of code. If you're interested in the full source code of this sample, just leave a comment and I'll post it here (that's what I call lazy sample upload - long live the functional approach!). Beside extension methods, this sample also demonstrates: auto-implemented properties, object initializers and lambda expressions! Try and spot them all!


More examples


I'll go ahead and post more examples of extension methods and how they help me write cleaner code everyday.



1. Collections


It's nice to be able to check if a collection doesn't contain items in a single step:


        public static bool IsEmpty<T>(this ICollection<T> possiblyNullCollection)
{
return possiblyNullCollection == null || possiblyNullCollection.Count == 0;
}

ICollection<T> lacks AddRange:


        public static void AddRange<T>(this ICollection<T> collection, IEnumerable<T> items)
{
foreach (var item in items)
{
collection.Add(item);
}
}

Or adding several items separated by commas:


        public static void Add<T>(this ICollection<T> collection, params T[] items)
{
foreach (var item in items)
{
collection.Add(item);
}
}

It's nice to be able to call a given method for each element:


        public static void ForEach<T>(this IEnumerable<T> collection, Action<T> action)
{
foreach (T item in collection)
{
action(item);
}
}

Or have a composable GetValue on Dictionary that doesn't throw:


        public static V GetValue<K, V>(this IDictionary<K, V> dictionary, K key)
{
V result;
if (dictionary.TryGetValue(key, out result))
{
return result;
}
return default(V);
}

2. Strings


For strings, everyone already seems to have developed their own little library. So I think I won't be original if I share these:


        public static bool IsEmpty(this string possiblyNullString)
{
return string.IsNullOrEmpty(possiblyNullString);
}

public static void Print(this string str)
{
Console.WriteLine(str);
}

public static void MessageBox(this string str)
{
global::System.Windows.MessageBox.Show(str);
}

I also found it to be very convenient to have the following (trivial implementation, doesn't throw):



        public static int? ToInt(this string textNumber)
public static bool? ToBool(this string boolValue)

These guys rock because they easily compose and don't distract me with the necessity to call TryParse or such. BTW I think that the composability of any TryParse method is not very good, in case you haven't noticed.


3. XML


Last but not least, a nice enhancement to XElement:


        public static string GetElementValue(this XElement element, string elementPath)
{
if (elementPath.IsEmpty())
{
return element.Value;
}

XElement subElement = element.Element(elementPath);
if (subElement == null)
{
return null;
}

return subElement.Value;
}


It doesn't throw, which saves me a lot of effort every time I want to call it - I don't have to be afraid that Element() can return null.


Conclusion


Of course, there are caveats. Many people critisize extension methods for the lack of discoverability. Indeed, extension methods for a type only appear in the Visual Studio IntelliSense if you add a using declaration with a namespace where the extension methods are declared. This is currently a discoverability problem.


Also, others mention that it is difficult to read existing code with extension methods because we don't know the meaning of methods and where they are declared. My answer - use F12 (Go to Definition) in Visual Studio.


Finally, there is a versioning problem.


But still, I think extension methods are so cool and they provide so many advantages, that it is well worth using them anyway. Especially if you belong to those people who Know What They Are Doing.



kick it on DotNetKicks.com

11/23/07

Jacob Carpenter on named arguments in C#

Jacob Carpenter has an interesting post called Named parameters { Part = 2 }. As immutable types are very trendy these days (good!), questions arise how to initialize them. C# 3.0 has Object Initializers (where IntelliSense even kindly shows you the list of remaining uninitialized properties), but unfortunately we cannot use it because it requires the properties to be settable. Jacob came up with a pretty cool trick to use anonymous types to get a syntax similar to object initializers and still call into a constructor. This technique is somewhat similar to casting by example, where we also abuse anonymous types to reach our goal.

To further improve Jacob's strategy, I would probably turn NamedArguments into a factory and make it responsible for instantiating the CoffeeOrder object as well. One could use Activator.CreateInstance to create an instance of the CoffeeOrder type and return it directly instead. Thus, the code for initializing the object could be further reduced to:

var order1 = NamedArgs.For<CoffeeOrder>(new
{
DrinkName = “Drip”,
SizeOunces = 16,
});

11/16/07

John Rusk on Extension Interfaces

Sorry for not blogging recently, I was ramping up and getting started in my new role on the C# team. I love it here! The people are great, the job is interesting and I'm really proud to work in C#. There are a lot of interesting things starting here, like F# or other very exciting projects I can't talk about at this point ;-)

 

I posted recently about duck-typing and extension interfaces. John Rusk pointed me to his great article about extension interfaces. It was posted back in 2006 but I only discovered it recently (sorry). It was interesting to see Keith Farmer's comments on the article, especially because I'm now sitting two offices down the hall from him so I could go and ask him what he thinks about it in person. But I digress.

 

I like John's ideas and considerations, and I currently can't think of any caveats of implementing extension interfaces from the design point of view. From the implementation perspective, there might be a complication John warns about. To make an existing class implement an interface, you'd usually write an adapter class. Now the problem is: a reference to the adapter object won't be the same with a reference to the actual target object, and that might become a problem, e.g. when you'd like to compare objects. Being constructive, John also points to a possible solution involving CLR internal special cases like TransparentProxy (see an as-always-excellent post by Chris Brumme about it).