Natural Language Constructs

Yesterday I casually mentioned to Sean that in my code I seem to vastly prefer lambda over LINQ syntax. He translated that to mean that I probably prefer chaining my actions from one object to the next, or something like that. And, you know what? He was right. I thought about it a bit more today and what I discovered was the reason why I've never liked certain static method calls in C# (actually, I've never liked static methods in general and only grudgingly accept them where needed).

Taking this a bit further, I narrowed down a few key examples of static method calls I've never liked. Let's take a look at what are probably the two most common for me:

string.IsNullOrEmpty(input);
string.Format(input, args);

I can't tell you how many times I've begun typing a variable to check if it's null, only to remember that it's a string and have to back-track for a moment to make the method call. Or how many times I've begun typing a string only to later remember that it needs to be formatted and to back-track for a moment, etc. It's just a little thing, but it irks me a little bit every time.

(In fact, this is probably the reason why it took so long for me to catch on to using string.Format() instead of just concatenating strings together, which I've always done until recently. I hope all the places I've ever worked will forgive that.)

But no longer must I accept these things. For now I can write extension methods! Behold:

public static string FormatWith(this string s, params object[] args)
{
  return string.Format(s, args);
}

public static string IsNullOrEmpty(this string s)
{
  return string.IsNullOrEmpty(s);
}

You may be wondering if that second one will break if it's called on a truly null variable. It doesn't. Man, I love C#.

I can't speak for everyone else, but to me this makes the code so much easier to write. I feel like a weight has been lifted. It's all in how we look at what we're writing, I guess. For me it's about the subject at hand. In this case, the variable. I prefer to start with the variable and chain my commands to it accordingly. (This is also why I hate output parameters and things like Array.Reverse(), which by the way I've also replaced with an extension method). I mean, compare for yourself:

if (string.IsNullOrEmpty(s)) return false;

vs.

if (s.IsNullOrEmpty()) return false;

return string.Format("The value is: {0}", s);

vs.

return "The value is: {0}".FormatWith(s);

At the very least, it's less typing. But, more to the point, it starts with the subject and then proceeds with the actions on that subject. That's how we learned to speak English, that's how some of us want to write our code. It just seems like a more natural language construct, doesn't it?

Either way, I've been making a lot of these extensions, and getting ideas for more from various sources online. StackOverflow has a great thread on the topic.

[Edit: I renamed IsEmptyOrNull() to IsNullOrEmpty() because, unlike Format(), the compiler doesn't seem to complain that it's a name already in use. It can tell the difference between the two.]