Brendan Enrick

Daily Software Development

Users Don't Read Your Text

A few days ago Jeff Atwood wrote a great post about users. This is my post adding to his.

I also develop applications, and user interfaces is a common topic of discussion. The interface of an application is one of the most important aspects of it. What a lot of people seem not to realize and Jeff nicely highlights is that users don’t read anything. Trust me. I use a lot of applications, and I avoid reading anything that is more than six or seven letters long.

If I have to read something to use an application you’re probably going to lose me. I am not here to learn your application I am here to use your application. Jeff shows this image as what a user sees on Stack Overflow when writing a question.

su-ask-what-the-user-sees

I think he is a little bit off here. Why? Oh I don’t know, because he includes the preview. I might look at the preview, but only if I am concerned about how something is formatted. If I don’t think I did anything complicated I don’t bother checking the preview. I figure I should be able to use this page while only really reading this section.

su-ask-what-the-user-really-sees

When I need to reference something I will find it on the page. However, the 90% case is going to be this. I’ll make a decision if I need to look elsewhere, and I’ll be annoyed when I have to.

I use Stack Overflow and I think the interface is great Jeff. You support standard keyboard shortcuts, so I can learn what they do and how to format them by only observing the editor and occasionally the preview section. When I need a list I know to use the buttons at the top. Anything that is a standard convention I will follow. You give me a toolbar of choices and keyboard shortcuts and I’m set.

I think it is most important to follow common practice if you want things right. I am not sure why people have such trouble with Stack Overflow’s editor.

Working with the Default Layout of Silverlight RadCharts

The default layout for a RadChart works for most situations. It has a ChartArea, a ChartLegend, and a ChartTitle. These are easy to work with, and if you want you can break from the norm and create your own custom Silverlight Rad Chart layout. If you’re sticking with the default you almost certainly have some settings and properties to which you will want to make adjustments. In order to do that you might define these in the XAML.

<UserControl x:Class="MyApplication.UI.Charts.SuperSweetChart"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
    xmlns:telerikChart="clr-namespace:Telerik.Windows.Controls;assembly=Telerik.Windows.Controls.Charting" 
    xmlns:chart="clr-namespace:Telerik.Windows.Controls.Charting;assembly=Telerik.Windows.Controls.Charting" 
    Width="400" Height="300">
    <Grid x:Name="LayoutRoot" Background="White">
        <telerikChart:RadChart x:Name="Chart1" 
                               Loaded="Chart1_Loaded">
            <telerikChart:RadChart.DefaultView>
                <chart:ChartDefaultView>
                    <chart:ChartDefaultView.ChartArea>
                        <chart:ChartArea LegendName="CustomLegend" NoDataString="">
                            <chart:ChartArea.DataSeries>
                                <chart:DataSeries x:Name="DataSeries1" >
                                    <chart:DataSeries.Definition>
                                        <chart:PieSeriesDefinition 
                                            LabelOffset="0.6d" 
                                            ShowItemToolTips="True" 
                                            ItemToolTipFormat = "#XCAT" 
                                            DefaultLabelFormat = "#%{p0}" />
                                    </chart:DataSeries.Definition>
                                    <chart:DataPoint YValue="35" />
                                    <chart:DataPoint YValue="15" />
                                    <chart:DataPoint YValue="55" />
                                </chart:DataSeries>
                            </chart:ChartArea.DataSeries>
                        </chart:ChartArea>
                    </chart:ChartDefaultView.ChartArea>
                    
                    <chart:ChartDefaultView.ChartLegend>
                        <chart:ChartLegend x:Name="CustomLegend" 
                                           UseAutoGeneratedItems="True" />
                    </chart:ChartDefaultView.ChartLegend>
                    
                    <chart:ChartDefaultView.ChartTitle>
                        <chart:ChartTitle>
                            <TextBlock Text="Traffic Sources"/>
                        </chart:ChartTitle>
                    </chart:ChartDefaultView.ChartTitle>
                    
                </chart:ChartDefaultView>
            </telerikChart:RadChart.DefaultView>
        </telerikChart:RadChart>
    </Grid>

Notice the three parts are the ChartArea, the ChartLegend, and the ChartTitle. Use the properties of these to make your adjustments. If you don’t want to change these in the XAML then don’t include them. If you’re going to work from the code behind it doesn’t hurt to have these here, but it can be useful.

You can access these in the code behind by either declaring their x:Name property or by referencing them from the RadChart’s x:Name like this. Chart1.DefaultView.ChartArea.

Plus keeping things in here keeps designers happy, and we design-challenged people really appreciate happy designers willing to assist us.

Implementing IEnumerable and IEnumerator

Working with a foreach loop is the primary reason to implement the IEnumerable and IEnumerator interfaces. You’ll want one of each of these to work with the loop.

I am going to do an example DateRange class which will implement IEnumerable<DateTime> and will allow us to iterate through a non-existent collection of DateTime objects.

Note: I am aware of the fact that I could achieve the same result with a for loop. I find the foreach loop more readable.

First we need to create a basic DateRange class. A range can be defined as a StartDate and an EndDate, so I’ll start there.

public class DateRange
{
    public DateRange(DateTime startDate, DateTime endDate)
    {
        StartDate = startDate;
        EndDate = endDate;
    }
 
    public DateTime StartDate { get; set; }
    public DateTime EndDate { get; set; }
}

So this DateRange could be useful on its own, but we want to be able to iterate this collection using a foreach. So to start we need to implement the IEnumerable<DateTime> interface.

public class DateRange : IEnumerable<DateTime>
{
    public DateRange(DateTime startDate, DateTime endDate)
    {
        StartDate = startDate;
        EndDate = endDate;
    }
 
    public DateTime StartDate { get; set; }
    public DateTime EndDate { get; set; }
 
    public IEnumerator<DateTime> GetEnumerator()
    {
        return new DateRangeEnumerator(this);
    }
 
    IEnumerator IEnumerable.GetEnumerator()
    {
        return GetEnumerator();
    }
}

 

Notice here that we now need to get the IEnumerator<DateTime> object in the GetEnumerator() method. I jumped the gun a bit and I’ve called a class that doesn’t exist yet. I’ll make another class and implement the required methods for the IEnumerator interface.

public class DateRangeEnumerator : IEnumerator<DateTime>
{
    private int _index = -1;
    private readonly DateRange _dateRange;
 
    public DateRangeEnumerator(DateRange dateRange)
    {
        _dateRange = dateRange;
    }
 
    public void Dispose()
    {
    }
 
    public bool MoveNext()
    {
        _index++;
        if (_index > (_dateRange.EndDate - _dateRange.StartDate).Days)
            return false;
        return true;
    }
 
    public void Reset()
    {
        _index = -1;
    }
 
    public DateTime Current
    {
        get { return _dateRange.StartDate.AddDays(_index); }
    }
 
    object IEnumerator.Current
    {
        get { return Current; }
    }
}

 

These are the handful of methods we implement for the IEnumerator<DateTime> interface. These are all about moving to the next object and getting the current object. Resetting and Disposal of the object are less important, so make sure you read MoveNext and Current.

Keep in mind here that I could have used a collection for this, but I didn’t because I don’t need one. The calculation to get the items was easy enough.

var dateRange = new DateRange(DateTime.Today.AddDays(-6), DateTime.Today);
foreach (DateTime date in dateRange)
{
    Console.WriteLine(date.ToShortDateString());
}

Output:

10/20/2009
10/21/2009
10/22/2009
10/23/2009
10/24/2009
10/25/2009
10/26/2009

Visual Studio 2010 Beta 2 is Here

As of today Visual Studio Beta 2 is available to the general public. There is a VS 2010 Beta 2 iso available for download. It has some really nifty features. I’ve been playing around with it.

First off I will say that it actually looks very cool.

StartPage

I think they did well. The new start page here is also a lot cleaner. I’ll be looking to see how to customize it a little.

Creating new projects is a lot better. Far less intimidating in this new default view. If they can keep the clutter down on this I will be very happy.

NewProject

So I created an “Empty ASP.NET Web Application”. I noticed one crazy thing about it. I don’t think there are enough references here? Maybe we need more. C’mon guys. Seriously. Who wants to start with all of these in there? I chose the “Empty” one so I wouldn’t have all of this clutter.

StandardReferences

But wait! They did remove the clutter. Guthrie had mentioned they were doing this. I am just now seeing the web.config and it is AWESOME!

DefaultWebConfig

There is barely anything in the web.config. Yipee! Hooray!

“Navigate To” is a nice feature. I already use ReSharper, so the wow factor is gone. I am glad to have it integrated though.

NavigateTo

We were able to move the editor window around in previous versions of Visual Studio, but this feels a lot nicer, and anyway it’s still useful. Grab an editor window and decide where to put it. Much more freedom for splitting the screen this way.

 

MoveEditorWindow

You can do stuff like this. And have three editors open at once (you better have a lot of screen real estate before you try this).

TiledWindows

Or if you actually use the designer in Visual Studio you can split it along with the code behind file. Getting you the Design, Source, and Code Behind.

TileWithSplitView

This looks like a pretty nice thing they’ve build here. I figured with the big changes they were making that this version of VS would be lacking in too many upgrades. It seems they’ve managed to pull off some nice stuff here.

I am sure I’ll discover more new stuff at some point. Luckily the same feel is here, so just need to learn all of the little changes and additions.

When Should You Comment Your Code

Comment your code when it is hard to understand or determine your intent, because your code is crap. Yep, that is pretty much the best time to comment your code. When I was in college I was told to make sure that I commented my code. I always wondered why. Now I know. Comments really tended to clutter things and make it less clear what I was trying to achieve. I’ve written plenty of comments, but I know that when I use a comment that it means my code sucks.

Comments take time to write, they take up valuable space, they add clutter, and they’re often out of date. So why do we write them? We write them because there is something confusing about some code. Or something that we need to tell future readers about the code.

I very much enjoy being reassured of the way I do things by the books I read. I’ve been reading Code Complete, and it makes me glad they I blatantly disagreed with the people who told me to comment my code. Why? Because the author of the book tells me the exact opposite. I’ve often used the phrase, “code should be self-documenting.” I am not sure from whom or from where I first heard that, but it also affirmed my belief about comments.

The proper use of comments is to compensate for our failure to express ourself in code. Note that I used the word failure. I meant it. Comments are always failures. We must have them because we cannot always figure out how to express ourselves without them, but their use is not a cause for celebration.

Aside from the misuse of the English language, that is an excellent paragraph. I’ve never liked writing comments, and I doubt I ever will. It is interesting how some programmers swear by them. I think they are the same programmers who use single-letter variables, magic numbers, and hundred line methods.

I highly recommend reading through the best comments in source code question on StackOverflow.

Remember kids, anytime you feel the need to write a comment, fix your code instead. You’ll thank yourself down the road. You might be the future developer maintaining the code.

A few steps to follow. (These are the easy ones. Harder ones take more than a bullet point to explain and justify.)

  • Rename variables to more expressive names.
  • Extract methods so people know what you’re doing.
  • Extract classes to handle each responsibility.

Null Reference Exception on Instance Methods

Recently I was reading through a bunch of interesting blog posts. I was looking for information about the use of callvirt in C#. Callvirt can be used to call both virtual and non-virtual methods, and in fact is how all methods are called in C#. I don’t know how much of a performance decrease there is based on this, but I doubt it is much of one. I stumbled across this interesting post covering why C# uses callvirt from Eric Gunnerson’s blog.

We had gotten a report from somebody (likely one of the .NET groups using C# (thought it wasn't yet named C# at that time)) who had written code that called a method on a null pointer, but they didn’t get an exception because the method didn’t access any fields (ie “this” was null, but nothing in the method used it). That method then called another method which did use the this point and threw an exception, and a bit of head-scratching ensued. After they figured it out, they sent us a note about it.

We thought that being able to call a method on a null instance was a bit weird. Peter Golde did some testing to see what the perf impact was of always using callvirt, and it was small enough that we decided to make the change.

Now that certainly is odd behavior. I don’t know how I feel about it though. So basically one could have been able to call instance methods on null instances of an object as long as they didn’t access any members of the object itself. First I will say that methods with fewer dependencies are great.

So C# was of course adjusted to disallow this, but if it hadn’t then this could potentially work.

using System;
namespace NullInstanceMethod
{
    class Program
    {
        static void Main(string[] args)
        {
            Enrick brendan = null;
 
            Console.WriteLine(brendan.Awesome());
        }
    }
    class Enrick
    {
        public string Awesome()
        {
            return "Awesome";
        }
    }
}

 

Yep, that method isn’t static. It’s an instance method, but you would have been able to call it.

So to see that in action why don’t we disassemble this code and make the change directly to the intermediate language.

First we need to get the IL using ildasm, so open up the VisualStudio 2008 Command Prompt and type this command.

ildasm PathToTheExecutable /out:new.il

This will create a file “new.il” in our VS Command Prompt working directory.

Now we can open this in our favorite editor and we will see a bunch of code. We are just looking at this main method though.

.method private hidebysig static void  Main(string[] args) cil managed
  {
    .entrypoint
    // Code size       16 (0x10)
    .maxstack  1
    .locals init ([0] class NullInstanceMethod.Enrick brendan)
    IL_0000:  nop
    IL_0001:  ldnull
    IL_0002:  stloc.0
    IL_0003:  ldloc.0
    IL_0004:  callvirt   instance string NullInstanceMethod.Enrick::Awesome()
    IL_0009:  call       void [mscorlib]System.Console::WriteLine(string)
    IL_000e:  nop
    IL_000f:  ret
  } // end of method Program::Main

See IL_0004 there is our callvirt that makes the call to our instance method. If we change that to a regular call we should be good.

Now we just put the IL back into the assembly.

ilasm new.il

And we execute it and here is the result.

CallSuccess

 

 

And there you have it. I just called an instance method on a null instance of a concrete class without getting a null reference exception? Strange? Yes. Wrong? I don’t know if it really is.

For your homework I would like you to consider what would happen if I were calling an interface’s method instead of a concrete class.

Why I Prefer Web Application Projects

Over the summer, Nimble Pros brought on some new interns. We of course brought them up to speed on how we do things here. We like the integration process of bringing new employees into the mix immediately involving them in the process the entire team is involved with. To help get them up to speed we use a combination of pair-programming, book and article reading, and formal instruction.

As I am sure anyone who uses Visual Studio for web development knows, there are two main ways to go about creating the site that you’re going to develop. There is the web application project (WAP) and the web site (ignoring MVC of course).

Back in the days of ASP.NET 1 there was only one way of doing things, web application projects. ASP.NET 2 got rid of WAPs and replaced them with web sites. Not entirely sure why, but it did not take long before Microsoft added Web Application Projects back into the mix. These were able to be installed and added into Visual Studio so they could be used again.

I of course switched to these as soon as they were readily available. The title of this post kind of gives that away. I switched for a few reasons including the dueling assemblies issue which can occur with web sites. I have written about dueling assemblies and some of the differences between these methods of developing sites before.

The main reason why I prefer having a project is that I like being in control. Now you might wonder how I can have more control with a project file. It might seem that the less controlling approach would give me more control, but it is not the case. The loose collection of files, lovingly referred to as a web site is hard to control. I can’t say what is included I can’t say what is excluded. My only control is the relative locations of files. Inclusion of a library? Oh that is a refresh file in the bin folder.

Sure I can get some control in a web site’s loose structure, but I feel that I get so much more control from the project file. I have something obvious to point MSBuild to. I have settings and targets I can manipulate in the file. I have direct control of which files are in the project. Heck I can control which version of a dll I am using which means no more dueling assemblies. Hooray!

Perhaps you disagree. I prefer the WAP to the web site. Do you have any good reason to think otherwise?

Recommended Reading List

Just like many other developers I know, I have a stack of books I intend to read high enough that I could not hope to finish them ever. I know that the stack will increase in size as fast as I finish the books. I have plenty of technical books I intend to read as well as a large quantity of those which are purely for my own entertainment.

Required Developer Reading

I think it is very important to continue reading and learning to be a better developer. Here at Nimble Pros we make sure that our developers know what they should be reading, so every time we hire someone I make sure that they get there hands on these books. While not required, we highly encourage our developers to take the time to read these excellent books.

Code Complete – This is a classic that is on a lot of reading lists. I read this one a few years ago, and I really think that you should read it if you have not. It is a fairly large book that covers a variety of topics with a great deal of depth and breadth. It really is worth the time and effort to read.

Working Effectively with Legacy Code – While the name of this book is somewhat misleading based on people’s definition of “legacy code”, I still believe this is one of the most important books for every developer to read. Michael C. Feathers wrote an excellent book with this one. Every developer is going to need to work with legacy code constantly during their time as a developer. We don’t always work on green-field projects, and this book takes a hands-on approach to explaining how to deal with and fix up legacy code.

I am Currently Reading

Yesterday, I started reading Clean Code, which is a book I am already fascinated with. I mention this because I believe it will make the above list once I am done reading it. I have only just started reading it, but I’ve already got plenty of notes I’ve taken as I’ve been reading it. I plan on discussing as much as I can about the book and its topic as I  read it.

Look forward to some blog posts responding to this great book.

The Joy of Removing Code

Removing code is one of my favorite activities. Isn’t it one of yours? As a software developer I strive to write less code. Sounds kind of funny, but what I mean is that I want the code that I write to be reused as effectively as possible. Having less code means that maintenance is easier. I can fix things faster, change things faster, find things faster, and figure things out faster.

This is a very good case of “less is more”, which is one reason why I love removing code. I really enjoy getting more or even equivalent work done with less code.

I just finished eliminating a constructor. Why? Well, it really was not needed. As it turns out there was a more appropriate constructor to use for the class. Not sure when or why the constructor was created, but it doesn’t really matter. I am fairly certain that nothing is using it after my removing it. Code still compiles. Tests still pass.

This does a lot of good things. It makes the class less intimidating by dropping the line count. It makes clearer which constructor to use when there are fewer of them. If I need to make a change to the constructor by either adding or removing a parameter for example there is only one place to do this now. Before there were two places.

I love writing code, but I also enjoy removing excess code. It just makes things simpler, which is exactly how I like things. I want my code to be just complex enough to work. When I am refactoring old code this is one of the best things to do. Chopping off all the bits and pieces of unneeded legacy code is progress.

Has anyone else removed any code recently they were glad to be rid of? Anyone eliminate any entire class libraries or anything cool like that?

“Do you want complexity with that?”

“No, thank you.”

Fast Beats Right, a Principle of Mediocre Programming

Steve Smith just posted an interesting set of anti-principles, anti-patterns, and anti-practices that make up mediocre programming. In the post one of the principles of mediocre programming that Steve mentions is,

Fast Beats Right (FBR) – It’s more important to get something done that probably works, or that works right now even if it will be hard to change later, than to spend time ensuring that it is correct or is well designed.

I think we’ve all seen people who code this way before. They’ll get the really quick, dirty solution in place. Steve also makes note of what he has experienced as management’s opinion of this behavior.

sometimes management may be OK with dictating that for a given feature or prototype, speed is more important than anything else

The really scary part here is that there are managers who think that faster == better. Some teams have programmers following this principle and the managers think those are the best programmers. Why? Well, that guy gets lots of new stuff done. These other guys don’t (because they have to clean up the crap the fast guy writes.) Sure, for any task that is small enough I can do the work really quickly without testing or structuring things correctly. However, it might not work for all cases. The code could be fragile. It is very hard to determine how well it will stand up. Down the road I might need to add on to that code, and it could be so bad that it needs to be completely rewritten.

I really hope that no one is stuck at an office where management believes that an FBR programmer is a good programmer.

Have you every worked with a coder like this? What was the opinion of developer from the management point of view?