Disclaimer: No boy scouts were harmed in the production of this post

The Boy Scout Rule is in my opinion a highly valuable mechanism for ensuring that a code base remains effective over time. The Boy Scouts of America have the rule “Leave the campground cleaner than you found it.”* Applying this to the code as it is maintained provides an efficient mechanism for ensuring code quality. The marginal effort required is relatively low as you are already working with it and hence the effort to understand the purpose and structure of the code is already required.

At this point I want you to imagine a boy scout cleaning a camp site while under the influence of significant quantities of amphetamines. Such a hypothetical boy scout is going to get their camp site very, very clean. And probably clean other camp sites as well even if, for instance, there are still people sleeping in the tents being packed away. Now that you’ve imagined all of this, you have some idea of the reputation I have for editing existing codebases.**

Continuous cleaning of a codebase is beneficial over the lifetime of a project but it must also be recognised that there are costs involved. In particular the additional changes complicate source control activities and require additional communications within the development team. There is also the inherent risk involved in any change to a software systen, The existence of these costs doesn’t mean that you should not improve the code as you go. It does however mean that you should be measured in how you do so.

When joining a project I will often go through a lot of the code and “tidy” it. This may involve cosmetic changes such as applying consistent formatting and removing unused namespaces. It may also involve restructuring of logic like reducing the level of nesting and extracting methods. I find this helpful in getting a handle on the structure of a system. Sometimes I may touch over half the files in a system. What I have learnt however is that many of these changes should be undone using the magic of source control. Generally I will keep a few key modifications related to the features on which I am working and discard the rest. This is not wasted effort as I have gained a better understanding of the system from the changes. Additionally many of the changes are made with automated tools and hence can be repeated efficiently later.

By distributing the changes over time the costs and risks involved are dramatically reduced. This is a good thing, even if it does go against my fundamental nature. My challenge now is not to block my inner boy scout but to ensure that he stays in rehab.

* I have no idea if this is true in Australia as during my brief time in the scouts I was The Worst Scout in the Entire World™

** And I do it all without drugs. Apart from my hopeless caffeine addiction.

I’ve recently had the need to link WCF and StructureMap (I don’t do “no IoC”). Jimmy Bogard has a nifty blog post with the requisite code to get this all working. The key class looks like this:

public class StructureMapServiceBehavior : IServiceBehavior
{
    public void ApplyDispatchBehavior(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
    {
        foreach (ChannelDispatcherBase cdb in serviceHostBase.ChannelDispatchers)
        {
            ChannelDispatcher cd = cdb as ChannelDispatcher;
            if (cd != null)
            {
                foreach (EndpointDispatcher ed in cd.Endpoints)
                {
                    ed.DispatchRuntime.InstanceProvider = 
                        new StructureMapInstanceProvider(serviceDescription.ServiceType);
                }
            }
        }
    }

    public void AddBindingParameters(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase, Collection<ServiceEndpoint> endpoints, BindingParameterCollection bindingParameters)
    {
    }

    public void Validate(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
    {
    }
}

This works, but it’s got nested loops and I’m mildly completely obsessed about this kind of thing. I’m putting this into my code which means that it’s now my responsibility. If I’m going to maintain it then it needs to fit with the rest of my code. Hence my new version:

public class StructureMapServiceBehaviour : IServiceBehavior
{
    public void ApplyDispatchBehavior(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
    {
        serviceHostBase.ChannelDispatchers
            .OfType<ChannelDispatcher>()
            .SelectMany(dispatcher => dispatcher.Endpoints)
            .Apply(endpointDispatcher => endpointDispatcher.DispatchRuntime.InstanceProvider
                = new StructureMapInstanceProvider(serviceDescription.ServiceType));
    }

    public void AddBindingParameters(ServiceDescription serviceDescription,
        ServiceHostBase serviceHostBase,
        Collection<ServiceEndpoint> endpoints,
        BindingParameterCollection bindingParameters)
    {
    }

    public void Validate(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
    {
    }
}

The addition of a little LINQ magic takes care of the nested loops and produces something I find cleaner and easier to maintain. It took little time to do and it gave me a better understanding of what this class done. I call that a win all round.

The Apply method is my variant of a ForEach that applies the supplied action delegate to every element of an IEnumerable<T>. I’m aware some people have objections to this but I argue the simplicity gain from the above is worth any notional degradation in purity.

I’ve got two separate projects at the moment that are both using query objects with NHibernate. The primary difference between the code is in the result transformer. One is using AliasToBeanResultsTransformer and the other AliasToBeanConstructorResultsTransformer. I had a problem with the former where the result object was not having any of its properties populated, which I determined to be because the projections were not having the alias defined (second optional property to the Add method). I just wrote a test for a query object in the project using AliasToBeanConstructorResultsTransformer to expose this problem so I could fix it (being a good little TDD developer). The only problem is that the problem doesn’t actually exist when using AliasToBeanConstructorResultsTransformer which obviously doesn’t need the alias specified.

This isn’t really that surprising (I had actually forgotten which result transformer I was using in the project). However I had expected that the AliasToBeanResultsTransformer would be able to match the properties extracted from the domain objects to the equivalent names in the result object. I can see why this isn’t the case due to the potential complexities of projection. I have now learnt not to expect this behaviour and also to test that the correct data is being projected.

I’m aware that “wierdness” is spelt incorrectly in the post title. It amuses me on a deeply trivial level.

One of my recent posts attracted a comment that I can only interpret as attempt at stealth spam. The text of the comment was sufficiently vague that it could be considered on topic (if not well reasoned or insightful). What indicated the comment was spam instead of badly argued partisan hackery was the comment subject and URL. A cursory glance through the comments may not have identified this. I can only assume this is an attempt to game search engines (although I doubt Google and friends consider my blog to be particularly influential).

The element I find interesting is the content used. The post in question was fairly harsh in a specific criticism of Microsoft. The content of the comment was a vague and unconvincing defence of Microsoft, but not a defence of any specific charge. This raises the question of how a spammer would identify the post as relevant. I can’t see it being done manually, regardless of how low someone is paid the economics simply couldn’t add up. This implies spammers are now automatically evaluating blog content to determine what content they can post that will best disguise their payload. Criticism of Microsoft is obviously a sufficient common occurrence that they can have suitably reusable content pre-written, as would doubtless be the case for many other scenarios.

I may despise them but if this speculation is correct it seems spammers have escalated the arms race again (or I’m horribly out of date in this area). I suspect I won’t be able to turn off comment moderation any time soon. Bastards.

Lest my previous post is interpreted as my not liking the .NET platform, here’s a collection of things that are great (and which you will have to prise from my cold dead fingers).

• Lambdas, Extension Methods and the Enumerable and Queryable classes. How did we ever live without them?
• ReSharper. Visual Studio is merely my ReSharper hosting environment. Please JetBrains, write a .NET IDE.
• TestDriven.NET. So much faster than anything else out there for running unit tests. Does one thing, does it amazingly well.
• Gallio and MbUnit. You can just tell when using it that it’s written by people who rely on it. My unit testing framework of choice.
• StructureMap. I’ve used a number of DI frameworks but StructureMap is the easiest to use and extend. Contains magic in all the right places.
• NHibernate. Admittedly not the easiest ORM to learn, but there’s no real challenger in terms of capabilities on the .NET platform.
• .NET Reflector. Not an every day tool, but invaluable for a variety of complex problems that would otherwise be major roadblocks. Highlights one of Microsoft’s wiser decisions (to not obfuscate the framework assemblies). Often the best option for examining an assembly even if you have the source code.
• ASP.NET MVC. Watching the development of this framework was an enormously positive thing, that kind of responsiveness to input and openness should be the standard for framework development not the exception. Plus it’s enormously superior to the mis-abstraction that is ASP.NET.
• AutoMapper. One of those “why didn’t I think of that” ideas that makes you feel like an idiot. Given how many errors I’ve found in handwritten mapper classes recently I’m not going back.

C# 2.0 introduced Nullable which gives us the ability to have nullable value types. This is handy and makes a number of scenarios easier (particularly database interaction in my experience). It’s very much in the category “nice to have”, useful but in most cases not essential. What I want is the inverse, reference types that cannot be null.

NullReferenceException is one of the least helpful exceptions you can expect to encounter. It carries very little information, generally leaving you with “something broke in there somewhere and its all your fault”. In almost all cases you get this exception because you forgot to do appropriate validation and do something more useful. Tracking the cause of a NullReferenceException can be tedious and time consuming, especially if all you have is the exception details (as would be the case from a logged exception from a production system).

Providing reference types that cannot be made null would eliminate this possibility. The compiler would require that any instance is immediately assigned a non-null value and any assignment cannot be to null. This would eliminate a lot of boilerplate code currently written to protect against nulls.

I’m not a language or virtual machine expert but I strongly suspect that introducing non-nullable types would be a significantly greater effort than was introducing nullable values types in C# 2.0. Checking that null may never be assigned to a value is likely to have nasty corner cases and working with the existing reference type behaviour could be quite complex. I have no expectation of this being in C# 4.0, but it would be nice to see it added to C# 5.0.

I’ve recently encountered code which looks something like:

var someInstance = someParameter as ISomething;
someInstance.DoSomething();

The problem with this code is that it is wide open for a highly unhelpful NullReferenceException. If someParameter cannot be cast to ISomething the as operator will return null. But this code doesn’t check if someInstance is null. It makes the assumption that someParameter may be case to ISomething, even though in practice this assumption may not hold.

There are two solutions to this. You may replace the use of the as operator with an explicit cast. This will throw an InvalidCastException if the cast cannot be performed, which at least is more informative that the NullReferenceException. It’s also going to be somewhat faster but the performance gain will be sufficiently trivial that this is unlikely to be a useful optimisation. It also makes the code more explicit in what it expects which aids readability.

The preferred solution would be to check the result of the as operator for null and handle this case appropriately. In many cases this would be to throw an exception, but this exception may be more informative than a generic InvalidCastException or NullReferenceException. In general you should throw a specific exception that provides meaningful information in the context, rather than a technical exception(what went wrong rather than how). In other cases there may be an appropriate alternate activity to be performed, or the method could simply do nothing in this case. Regardless of the appropriate behaviour it is important that it be considered and the code actually implement this behaviour.

My phone has been annoying me for some time, as it’s been slow and buggy. I’ve therefore decided to do a review.

To start with I need some tools:

Safety is of course paramount, so I’ll also need:

Reviewing can be dangerous. Kids, never review something without adult supervision.

Before review:

Here we see that in the event of attack by chisel the phone easily separates into two components, after which it ceases to function.

Further we can see that the device is vulnerable to chisel injection attacks:

Hopefully this will help you which your phone purchasing decisions in high-chisel environments.