I had a spirited discussion today about the use of the keyword
this
in C#. I love conversations like that. Great things come from debates over the inane and trivial in programming, I’ve discovered. Some of the most impressive growth I’ve experienced as a software engineer has stemmed from debates and conversations about the nuances of programming languages, platforms, and computer science in general.

This particular conversation got me thinking about the style and substance of programming, especially where the two converge. We’ve all worked somewhere that has a set of coding practices and standards by which you should adhere. Sometimes we agree, sometimes we don’t. But in the end, does it really matter how we format and structure our code at such a granular level?

I would say yes and no.

No, because two solutions that are functionally equivalent both get the job done. What is a coherent and obvious framework for one developer may or may not be coherent and obvious to another.

Yes in the sense that a standardized code base is easier to maintain and develop around. Yes in that there are sometimes good reasons to follow a given convention based on the project and the coding situation you find yourself in.

For example, in my discussion concerning the use of the keyword this
, we were debating its use in instantiated classes. The opposing view was that this
is unnecessary and that class level members should be prefixed for easy recognition within subsequent calls. This is a perfectly valid coding convention.

My view is that using the this
keyword is a more clear demarcation of the scope of a class member or property and separates the member from those scoped to the current method or code block. This is also a perfectly valid coding convention.

So is there a right answer? Maybe, but probably not. One could possibly make an argument that one solution could be more easily understood or that one is harder to refactor, but such a case would be hard to make convincingly, I think. It would be especially hard to sway someone of the opposite persuasion.

But having your convention challenged is immensely helpful. It forces you to really think about why you do what you do. Debate forces you to defend your ideas. You’re given an opportunity to both learn and to teach.

We can all learn from one another in the field of computer science. We ought to take and embrace the chance to debate with our colleagues. We can and should gather, as the ancient Greeks did in times past, to engage and strengthen our minds and those of our brothers.

Maybe leave the togas at home though.

I live for nifty code snippets. They make life so much easier. I also like .NET’s generics support. When I was recently writing a utility library for myself, I found myself wanting to convert command line arguments to a defined type. How would one go about converting an arbitrary argument passed as a string to an application specific typed value? Turns out it is extremely simple, if you use the wonderful world of generics!

You may be familiar with the Convert static class in .NET. To perform our trick, we’re going to use Convert.ChangeType(object, Type) to convert a generic type of T to a given type, determined by the caller of the method.

/// 
 Converts an  to a type . 
///  Generic type parameter. 
///  The object. 
///  The given data converted to a type  
private static T ConvertToTypeT(object obj)
    where T : IConvertible
{
    var t = Convert.ChangeType(obj, typeof(T));

    if (t != null)
    {
        return (T)t;
    }

    return default(T);
}

Of particular interest in this code is the constraint that we put on the generic type T. We restrict T to types that implement the IConvertible. This will allow us to pass a generic object obj into our method, defining T as a specific type, and allows the Convert class to convert it to an object that boxes the typed value. All we do then is cast the value as a type T.

In the case of an invalid conversion type, we can’t return null because we need to return a generic type T. T may be a nullable type, but it may also be a non-nullable primitive type. For that reason, we need to return the default value of T by calling the .NET method default(T), which returns null for nullable types, or the default value defined for a primitive data type.

Let’s use our conversion method.

public static void DoSomething()
{
    string argument = Environment.GetCommandLineArgs().First();
    int intValue = ConvertToTypeT(argument); //We can convert to an integer.
    bool boolValue = ConvertToTypeT(argument); //We can convert to an boolean value.
    string stringValue = ConvertToTypeT(argument); //Remember this takes a generic object, so strings work as well.
}

Note: Thanks to some constructive feedback, I’ve made two updates. I updated the declaration of t so that no casting occurs. Instead, we check that Convert.Change(obj, typeof(T)) gave us something other than null, as it returns an object. If not null, we then cast t as a T, otherwise return the default value of T.