.NET (General)

Null Object pattern follow up

Scott Dorman — Fri, 04 Jul 2008 13:51:08 GMT

My earlier post on the Null Object pattern led to a few critiques about the fact that I was presenting an extension method to do what is essentially a very simple logical test, and, as a result, doesn’t provide much value.

For reference, here is the original extension method from that post

public static class NullObjectExtenstions
{
    public static bool IsNull(this object source)
    {
        return (source == null);
    }
}

Yes, this is an extremely simple method and performs a very basic logical test. However, consider the static IsNullOrEmtpy function on String (taken from Reflector):

public static bool IsNullOrEmpty(string value)
{
    if (value != null)
    {
        return (value.Length == 0);
    }
    return true;
}

I would argue that this is a relatively simple method and performs two very basic logical tests. What is the benefit to using IsNullOrEmpty? In a word, consistency. By using IsNullOrEmpty, I know that every time I need to perform this test it is executing the exact same code in the same order. I don’t have to worry about someone accidentally testing “Length == 0” before the “!= null” and causing a NullReferenceExcpetion.

This same benefit applies to the IsNull extension method. It introduces that consistency (although I agree this test is still very trivial) for testing nullability. As I mentioned in my comments, the better choice for the extension method would probably have been an IsNotNull method. Here is a more complete NullObjectExtensions class:

public static class NullObjectExtenstions
{
    public static bool IsNull<T>(this T source) where T : class
    {
        return (source == null);
    }

    public static bool IsNotNull<T>(this T source) where T : class
    {
        return (source != null);
    }
}

Technorati Tags: CSharp, .NET

What is “Defensive Programming”?

Scott Dorman — Fri, 04 Jul 2008 13:26:10 GMT

My post on the Null Object pattern has generated some interesting dialog. One of the trends that I have seen is the idea that defensive programming means your code should fail as early as possible. I couldn’t agree less.

According to Wikipedia,

Defensive programming is a form of defensive design intended to ensure the continuing function of a piece of software in spite of unforeseeable usage of said software. The idea can be viewed as reducing or eliminating the prospect of Murphy's Law having effect. Defensive programming techniques are used especially when a piece of software could be misused mischievously or inadvertently to catastrophic effect.

While this is a good definition, I think it still leaves much to be desired. The Wikipedia entry goes on to say that defensive programming is one approach to improving software quality by “Making the software behave in a predictable manner despite unexpected input or user actions.”

I think this is the closest definition that actually conveys what defensive programming is all about. The idea behind defensive programming is that the application should behave in a consistent and predictable manner even in the case of unexpected conditions.

There are a lot of different ways to achieve this and they are all different depending on what you are trying to accomplish with the code, the programming language, and the control structures being used. For example, considering a switch statement:

switch (Orientation)
{
   case Orientation.Horizontal:
      break;

   case Orientation.Vertical:
      break;
}

This is perfectly acceptable code, right? Remembering that enumerations are simply numeric (generally integer) values, it is entirely possible for this switch to get passed a numeric value that doesn’t correspond to either Horizontal or Vertical. In that case, there is the possibility of the switch, or code following the switch, to crash. One option to handle this would be to add a default case to the switch:

switch (Orientation)
{
    case Orientation.Horizontal:
        break;

    case Orientation.Vertical:
        break;

    default:
        break;
}

In the default case you could throw an exception (if that’s the appropriate behavior) or, more likely, you take some action that ensures either the remaining code doesn’t execute or at least doesn’t crash.

Looking at another example, this time casting, shows some other ways to program defensively. A common scenario for casting is in UI programming and handling events.

private void button1_Click(object sender, EventArgs e)
{
    ((Button)sender).Text = "You pressed a button";
}

Again, this code looks perfectly reasonable and will work just fine until someone accidentally assigns this event handler to something other than a button. Once that happens, the code will crash since sender won’t be castable to a Button. There are several different ways to handle this but the simplest (at least in my opinion) is

private void button1_Click(object sender, EventArgs e)
{
    Button button = sender as Button;
    if (button != null)
    {
        button.Text = "You pressed a button";
    }
}

Yes, it is a bit more code but it also guarantees that no matter what happens if the object that raised the event is not a Button, the code won’t crash. You could have chosen to throw an exception (or just let the exception generated by the runtime bubble up the call stack until it’s handled, but that may not be desirable depending on what you are doing.

The bottom line is that catching exceptions (not throwing them, but catching them…and all exceptions will eventually be caught, but possibly not in a way you intended) is expensive and if there are techniques that allow your program to continue functioning properly or otherwise gracefully handle exceptional conditions, known as “defensive programming”, you should opt for that approach.

Technorati Tags: .NET, CSharp

Null Object pattern

Scott Dorman — Sun, 25 May 2008 22:28:23 GMT

I've been trying to catch up on my reading and came across this post by Fredrik Normén where he raises the question about returning null or using the Null Object pattern. Interestingly enough, last month while I was in Seattle for the 2008 MVP Summit I had a very similar discussion. The end result of that discussion was that null objects, and nullability in general, ideally should be treated as a "first-class" citizen in the CLR. This means that if you try to execute a method on a null object you get a null back in return rather than a NullReferenceException.

I tend to follow a very similar philosophy as Fredrik in that I return null in some circumstances and empty collections (or other appropriate defaults) in others. I think this style has grown from the fact that nullability has never been a first class citizen in most programming languages.

A few of the comments suggested the use of an extension method to accomplish Fredrik's idea of an "IsNull" property. Since we only have the ability to create extension methods, I created an extension method called IsNull that extends Object Class (System) to see if this would work.

This is, perhaps, the simplest extension method I've seen and worked with. The extension method is:

        1: public static class NullObjectExtenstions

       2: {

       3:     public static bool IsNull(this object source)

       4:     {

       5:         return (source == null);

       6:     }

       7: }

Using this extension method is also just as easy. Here is a simple console application I wrote to verify that this does indeed work:

       1: class Program

       2: {

       3:     static void Main(string[] args)

       4:     {

       5:         string x = null;

       6:         List<string> y = null;

       7:         CultureInfo culture = null;

       8:  

       9:  

      10:         Debug.WriteLine(x.IsNull());

      11:         Debug.WriteLine(y.IsNull());

      12:         Debug.WriteLine(culture.IsNull());

      13:  

      14:         if (!culture.IsNull())

      15:         {

      16:             Debug.WriteLine(culture.DisplayName);

      17:         }

      18:     }

      19: }

The output of this application is:

True
True
True

The last call to Debug.WriteLine(culture.DisplayName) is never executed since culture.IsNull() returns true so we don't hit the NullReferenceException.

MVP Summit 2008

Scott Dorman — Sat, 19 Apr 2008 17:05:34 GMT

I just got back from attending my first MVP Summit and have to say the level of access we received to the product teams and other people within Microsoft was outstanding.

Since this was my first Summit, I don't really have a frame of reference to know how it compares to previous years, but it did quickly become apparent to me that Microsoft really does listen to community as much as they are able. Obviously some groups and products are better able to do this than others, but that seems to be mostly due to where they are in the product lifecycle.

Going beyond the obvious technical and product information we received, the opportunity to network was equally impressive. With almost 1800 MVPs from around the world I was able to meet people from across the pond and locally, some of whom I already knew from online communities like The Code Project and GeeksWithBlogs. The closing keynotes by Ray Ozzie and Steve Ballmer were less presentation and more direct question and answer periods. I've seen Steve Ballmer present before but never in this type of setting and with the amount of candor he displayed.

Closing the Summit (and showing the real strength of the MVP community), what started out as a Florida MVP Geek Lager quickly turned viral with Twitter tweets and blog posts until approximately 75 (that was the last number I heard, but I left early) MVPs from around the U.S. (and I believe some other countries as well) descended on Kells Irish Restaurant & Pub (kudos to the bar staff that night, they did an incredible job keeping up with everyone!)

Next year's Summit has already been confirmed for March 1 - 4, 2009. I'm already starting to look for flights.

Technorati Tags: MVP Summit

Book Review: ASP.NET Data Presentation Controls Essentials

Scott Dorman — Fri, 28 Mar 2008 22:52:08 GMT

If you are an ASP.NET developer or want to become one, there are numerous books available that talk about the ASP.NET framework and/or how to build web sites using ASP.NET. Pact Publishing has a book that focuses specifically on the data presentation controls that are available in ASP.NET, including ASP.NET 3.5 called ASP.NET Data Presentation Controls Essentials by Joydip Kanjilal.

The book provides a good introduction to the basics of how data binding in ASP.NET works and then expands on that introduction to cover the new (in ASP.NET 2.0) data source controls, including the Object, SQL, and XML data source controls.

From there, the book focuses a separate chapter on the working with each of the different types of data presentation controls:

List Controls
- ListBox
- DropDownList
- CheckBoxList
- BulletedList
- RadioButtonList
Repeater
DataList
DataGrid

The List Controls chapter covers the basics of how to bind data to each of the different controls and presents a simple working example for each one. It also walks you through implementing a custom list control, by creating a custom CheckBoxList control. The chapter on the Repeater control shows how to do basic data paging and sorting, while the DataList and DataGrid chapters also show how to implement data editing.

The remainder of the book focuses on how to display different views of your data using the GridView and offers a good comparison between the GridView and DataGrid controls and then taking a deeper look at using the DetailsView, FormView and TreeView controls. The techniques presented in these two chapters show explain of the more common visual modifications in fairly simple to understand terms, including how to change the row color using a checkbox, displaying a cell tool tip and how to implement a hierarchical GridView. The last chapter focuses on LINQ and how to query data using LINQ to bind to the Listview and DataPager controls.

Overall, while the style of writing in the book was a little hard to follow at times, the technical content of the book appeared to be both accurate and thorough, providing a very good look at the various data-bound presentation controls available in ASP.NET.

Orlando Code Camp 2008 - Thanks!

Scott Dorman — Sun, 23 Mar 2008 23:58:16 GMT

I just got back from Orlando Code Camp 2008 and wanted to thank everyone who was involved in organizing it and everyone who came out to attend sessions. I believe there were about 250 people attending with about 40 speakers presenting on over 50 topics.

For those of you who attended my talks on memory management fundamentals - "Thank you!". I had a great turnout at both sessions, with about 18 people at each. I got a lot of great questions from everyone and some really good feedback as well. If you missed the talks, or attended and want a copy of the slides, they are available from my SkyDrive public folder:

Technorati Tags: CodeCamp

New Lineup of SlickEdit Tools

Scott Dorman — Thu, 20 Mar 2008 20:18:18 GMT

I have talked about the SlickEdit Tools and Gadgets in the past (here and here) and have always been impressed with both of them. Previously, the SlickEdit Tools were only available for Visual Studio 2005. Now that Visual Studio 2008 is here, SlickEdit has released an update that works with both VS2005 and VS2008.

The catch here is that this is much more than a simple update. The major difference is that the tools have been organized into two products: the Editing Toolbox (datasheet), which contains all of the same tools available in version 1.0, and the Versioning Toolbox (datasheet).

The Editing Toolbox provides a very useful collection of utilities that add convenience to your daily programming tasks by:

Aliases and Acronyms:
Use directory aliases to save keystrokes and mouse usage when opening files. Use acronym expansion to save keystrokes when typing class, namespace, or function names in your code.
Auto Code Doc Viewer
Extract header comments into MSDN-like documentation, fully linked HTML help that can be browsed in Visual Studio as a tool window and exported for sharing with others.
Code Annotations
Insert comments and notes about code without actually modifying the source file.
Comment Wrapping
Enable automatic wrapping of any type of multi-line comment as you type. You can also reflow existing comments in the current file.
Icon Extractor
Simplify the task of finding quality icons and applying them to your applications.
Quick Profiling
Fine-tune your profiling to get information about a specific section of code. This feature allows you to time many cases that are not possible with standard profilers, such as timing complex loops, recursive functions, and the time between an object’s creation and disposal.
Regex Evaluator
Interactively create and test regular expressions, which are used to express text patterns for searching.
Code Navigation
Use keyboard shortcuts to jump from a symbol to its definition and to list all references for the current symbol.
Word Completion
Use commands to search for and insert additional text from a matching string.

The Code Annotations feature is new in version 2.0 and is a great feature for collaboration and code reviews. It allows you to store annotations marked as "Bug", "Comment", and "Task". These annotations don't actually change the source file, they are stored in an external file. Annotations can be scoped as personal, project, or workspace.

The really nice thing about the Code Annotations window is that, unlike the Visual Studio Task List, the annotations are still displayed even when the source file is closed.

You can see all of the information about the annotation at a glance, including the full code element that is associated with that annotation.

The Versioning Toolbox allows you to view your source control activity and help you understand when and where changes are being made and by whom. Easily understand and navigate your source code by using these powerful features:

Backup History
View, compare, and restore versions of files without having to use source control.
CVS/SVN Source Control
Use CVS and Subversion source control commands directly in the Solution Explorer.
DIFFzilla®
Provides editable dynamic differencing and merging for files, directories, and source trees.
Find Version
Find the versions of one or more files that match specific criteria, such as which files were checked in by a certain user over a certain amount of time.
Line Version Info
View details about the check-in that last affected any specific line in a source file.
Version Graphs
View graphs depicting different historical aspects and trends of selected source-controlled files.
Version History
View the history of each version of a source file, including check-in comments, date, author, branches, and labels.
Visualizations
Uses color schemes to visualize the version for each line of code in the editor window. Allows you to answer the questions: ‘Who wrote this?’ and ‘How old is this?’ Different color schemes allow you to focus on specific users, dates, or labels.

I think the most promising features here are the Visualization and the fact that all of these utilities work with CVS, SVN, TFS, or VSS in exactly the same way. There is only support right now for TFS if you have TFS 2005 installed, but the developers at SlickEdit are working very hard on getting TFS 2008 support worked out, which will allow you to work with either TFS 2005 or 2008. This update should be available soon.

The best part of the new SlickEdit Tools is the price. Each Toolbox is available for $49. If you aren't sure if the tools are for you, download the free trial. Once you install them, I think you'll find that they will quickly become part of your every day development experience.

How big is the .NET Framework?

Scott Dorman — Wed, 19 Mar 2008 03:44:17 GMT

No, this question isn't asking how much disk space is required by the Framework. It's really asking "How complex is the .NET Framework for developers?" As you might guess, the answer is: It's pretty complex.

All joking aside, this is neither an uncommon nor unreasonable question and answer. The reality of it is that the .NET Framework is a very complicated application programming interface (API) but is designed in such a way to expose that complexity gradually (at least in most cases).

Brad Abrams has an excellent post that shows this complexity in a very easy to understand set of graphs. The side-benefit to these graphs is that they show the evolution of the Framework over time, not just the current release.

The interesting thing that these graphs show is that in every category the amount almost tripled between versions 1.0 and 3.5 of the Framework in almost 6 years. Given the complexity of a lot of the changes between versions that is an incredible amount of work.

NameValueCollection and .NET Configuration Files

Scott Dorman — Mon, 17 Mar 2008 00:00:02 GMT

I spent most of yesterday trying to figure out how to make use of a NameValueCollection in a .NET configuration file. After wasting almost the entire night fighting with this problem, I thought I would let everyone know that it is possible, and easier than you might think. (By the way, this was a clear case of working too long on the problem. After a good nights sleep, I solved this in under 5 minutes.)

At this point you might wonder why this was so difficult. The largest and most significant problem is the fact that NameValueCollection isn't serializable (KB 814187). The reason for this is that NameValueCollection doesn't implement ICollection but extends NameObjectCollectionBase instead. The recommended solution is to use a SoapFormatter to serialize and deserialize the collection. While using the SoapFormatter does work, it seemed like a very complex solution for a seemingly simple problem.

Not wanting to over-engineer my solution, I started searching the web for alternatives. I found several newsgroup postings that all said to use the SoapFormatter since that was the recommended solution and the only way to go. Not having drunk too much blue kool-aid, I kept searching. That search turned up an article by Keyvan Nayyeri that shows how to created a serializable NameValueCollection. This approach was intriguing and certainly seemed to be a more useful solution than using the SoapFormatter, but again it seemed like a lot of work.

Keep in mind, all I wanted to be able to do in the configuration file was to create a section that looked like this:

        1: <copyFiles>

       2:   <add name="C:\Windows" value="*.dll"/>

       3:   <add name="C:\Temp"/>

       4: </copyFiles>

Continuing the search, I thought I found my answer. I stumbled across an article (".NET How To Create and Use Custom Name-Value Config Sections") that shows how to do this in 4 simple steps. Reading through the article, I realized that it is written using the the .NET 1.0 and 1.1 ConfigurationSettings, which is provided for backwards compatibility only. Since the application I'm working on is .NET 3.5 and taking advantage of many of the new language features, I wanted to ensure that I wasn't using any deprecated classes.

This is where I started running into additional problems. It seems that Microsoft provides a NameValueSectionHandler, which the article makes us of. The problem is that NameValueSectionHandler is architected following the .NET 1.0/1.1 model and implements the System.Configuration.IConfigurationSectionHandler interface. This is great if you want to use the deprecated ConfigurationSettings class; if you want to use the recommended System.Configuration.ConfigurationManager or System.Web.Configuration.WebConfigurationManager classes you are out of luck. They will only work with a class that derives from ConfigurationSection.

So, after all this I thought I was out of luck and would need to write my own configuration section handler. (Remember, this was about 1:00 AM.) After sleeping on it, I realized that there was a much simpler way. Along with the NameValueSectionHandler, Microsoft also implemented NameValueConfigurationCollection and NameValueConfigurationElement, which derive from the appropriate configuration classes to be used by the ConfigurationManager. After seeing that, I realized that all I needed to do was implement a NameValueSection which derives from ConfigurationSection.

This is where the solution becomes easy. In it's simplest most form, the NameValueSection looks like this:

       1: public class NameValueSection : ConfigurationSection

       2: {

       3:     [ConfigurationProperty("", IsDefaultCollection = true)]

       4:     public NameValueConfigurationCollection Settings

       5:     {

       6:         get

       7:         {

       8:             return (NameValueConfigurationCollection)base[""];

       9:         }

      10:     }

      11: }

As you can see, this is pretty simple. In order to use it, you declare the section in your app.config file:

       1: <sectionGroup name="customSettings">

       2:    <section name="copyFiles" type="NameValueSection, CustomConfiguration"/>

       3: </sectionGroup>

       4: <copyFiles>

       5:    <add name="C:\Windows" value="*.dll"/>

       6:    <add name="C:\Temp"/>

       7: </copyFiles>

To access this configuration section in code, you simply need to do this:

       1: NameValueSection nameValueSection = ConfigurationManager.GetSection("copyFiles") as NameValueSection;

       2: if (nameValueSection != null)

       3: {

       4:     NameValueConfigurationCollection settings = nameValueSection.Settings;

       5:     foreach (string key in settings.AllKeys)

       6:     {

       7:         Console.WriteLine(settings[key].Name + ": " + settings[key].Value);

       8:     }

       9: }

This is about as simple as it gets. Even though you aren't actually using the real NameValueCollection you are using the NameValueConfigurationCollection, which has almost identical behavior. This is the solution that I finally ended up implementing and it works great. As you can see, with a minimal amount of effort you are now able to use a NameValueCollection in your configuration files.

Technorati Tags: .NET, C#, NameValueCollection, ConfigurationManager

Code Signing

Scott Dorman — Sat, 01 Mar 2008 02:59:10 GMT

Ever since the .NET Framework was first release, Microsoft has always recommended that your code be signed. Windows Vista drives this point home even more with UAC and the Windows Error Reporting (WER) features, not to mention the fact that it's a requirement for Vista logo certification. John Robbins from Wintellect provides an excellent explanation of how to sign your code. As it turns out, it's a lot easier than many of you may have thought.