For those who are not vocabulary buffs, let’s get our definitions straight:

Pedantic: a narrow, often tiresome focus on or display of learning.

And that is exactly what kind of programmer we’re going to examine today.   It is a symptom of being a mid-level developer, who over-zealously tries to use the techniques of a senior developer. 

Certainly some people, if you are fortunate, have no idea of what I’m talking about.  But to be clear, and to allow introspection for those of us who might need it, I will give a couple solid examples.  One example involves exception handling and the other involves the ‘foreach’ statement.  These “are two basic topics,” you might say, so “what possible harm could someone do?”

Pedantic Exception Handling

I love CodeProject.  If you are not already a fan, be sure to check it out.  It has countless fantastic articles, although it has one case of pedantism which is fodder for this presentation.  That particular article summarizes by saying that when you see exception-handling code like this:

public void AddBuddy( User buddy )
{
    m_buddies.Add( buddy );
    try        {
        ServerDB.AddBuddy( this, buddy )
    }
    catch( Exception ex )
    {
        m_buddies.Remove( buddy );
        throw ex;
    }
}

It would be better if it were transformed into this:

public void AddBuddy( User buddy )
{
    using ( ScopeGuard guard = new ScopeGuard() )
    {
        m_buddies.Add( buddy );
        ObjectGuard inserterGuard
            = ObjectGuard.Make( m_buddies, "Remove",
                        new object[] { buddy } );
        guard.Add( inserterGuard );
        ServerDB.AddBuddy( this, buddy );
        inserterGuard.Dismiss();
    }
}

Why does the author claim the latter exception handling is better than the former? Well because the first example, the author states, has “reduced readability.”  The second example the author admits is annoying given the need “to pass the ‘Remove’ method name” as untyped data, but overall he claims it “is more elegant and more practical than the usual try, catch and finally triad.”  He goes on “of course, there will be a performance hit due to the use of reflection.”

He must be a comedian.

Almost all developers understand how the exception handling works in the the first example.  In contrast, nobody but the author knows what on earth the second example is doing and yet the two examples are functionally equivalent.  The truth is, the author just wanted to show he knows how to use reflection. That is what makes it pedantic, and a detriment to the team who is confronted with the noise in the product code.

But let’s take one more example.

Pedantic Looping

Many developers are taking quickly to LINQ functionality in C#.  It’s powerful stuff.  And it is also an opportunity for the pedantic programmer to show-off needlessly.  Indeed, I’ve seen cases where programmers have endeavered to replace the “foreach” statement with an extension method.  In other words, instead of doing this:

foreach(MyClass aClass in MyCollection) {aClass.DoSomething;};

An alternative is proposed suggesting we should instead do this:

MyCollection.ForEach((MyClass aClass)=>{ aClass.DoSomething; });

I’m much relieved to see that Microsoft’s C# team has dismissed the idea, but of course that won’t stop the pedantics from writing that ‘ForEach’ extension, to show-off their ability to write extension methods and use lambdas.  The rest of us must simply navigate around the nonsense when reading such code.

Conclusion

Perhaps we proud programmers are all pedantic to some degree.  But certainly it is good to be reminded of the KISS principle, and to focus our talents on solving problems rather than making solutions looking for a problem.

Virtual Machines are amazing, but for my “rapid” integration testing needs I wanted something even better. So I was preparing to make my enterprise server “instantiable,” for the purpose of having several servers run in a single process. That is when I stumbled on an article about having entire applications run in an appdomain. I had already been using appdomains heavily via the System.Addin namespace (for plugins), but it had not previously occurred to me to launch executables in an appdomain.

What the article did not explain is that each appdomain you create (even those created recursively, as in my case) must be explicitly unloaded before terminating the process – to create a clean execution environment. But I finally got it working, and now I’m able to run dozens of inter-linked servers through scores of full-blown integration tests in seconds, and all from within a single process, on a single machine, launched from my Visual Studio unit-test IDE.

Now that is cool!