Wednesday, December 23, 2009

Useful Extension methods

I've posted in the past about the hazards in extension methods and how they can be easily abused. there are plenty of links out there specifying the cons of using this feature.
However, since the title got you in here, I'm assuming you are still interested.
I wanted to share some of the most common extension methods I use when writing code.

IsNullOrEmpty - I think we all know this method from the String class. Why not have the same capability on collections?
I did see plenty of samples on the web showing how to add this method to collections or arrays.
things like:
public static bool IsNullOrEmpty(this ICollection collection)
    return collection == null || collection.Count == 0;

This is all fine and will return True if the collection/Array are null or empty.
But hey, what about some other, non "ICollection" objects that implements IEnumerable like XmlNodeList?
For that purpose, we can't use the Length or Count properties since we don't have them.
So, let's work with the IEnumerator.
Initially, the enumerator is positioned before the first element in the collection so calling Current will throw an exception. By calling MoveNext we move the enumerator to the first element and the bool value will tell us if it is empty or not. Complicated?
public static bool IsNullOrEmpty(this IEnumerable iEnumerable)
    if (iEnumerable != null)
        return !iEnumerable.GetEnumerator().MoveNext();
    return true;

Now, since collections and arrays implements IEnumerable we are clear to go.
static void Main(string[] args)
    List<string> list = new List<string>();
    Console.WriteLine(list.IsNullOrEmpty());//This will print True
    list.Add("Some text");
    Console.WriteLine(list.IsNullOrEmpty());//This will print False

But wait, didn't I say "some" extension methods?
Another one I use when I'm writing console applications is:
public static void Print(this Object obj)
I use this trick when I need to change the output target according to configuration or command line input.
The result will look this:
static void Main(string[] args)
    List<string> list = new List<string>();
    list.IsNullOrEmpty().Print();//This will print True
    list.Add("Some text");
    list.IsNullOrEmpty().Print();//This will print False

Monday, December 14, 2009

Bad names

I've recently done code review for someone and stumbled on a GeneralUtils.cs file I didn't see before.
"OMG!!!" I said "it is general for sure, and provides some utils right? what kind of utils?"

Him: Grinning as if his hand was caught in the cookie jar. "A bunch of things related to X,Y and Z objects"
Me: "Well, X Y and Z handles 3 different things right?"
Him: "Yes but I didn't think they deserve an independent class"

The name is bad for sure and I got no objection on that. the thing is, it hides a much bigger problem. The object is doing too many things instead of focusing on just one. This means that the Single responsibility principle was violated.
I usually have a small question that clears the issue in a second. ask yourself what does the class/method is doing. if the answer is "It does x AND y" then a re-factor session should visit your code.

Him: "I see your point. I'll split them to 3. I thought of calling the first one XHelper"
Me: "Sounds good. this means that XHelper will help the X class right?"
Him: "No, I don't have an X class"
Me: "Let's suppose you have an X class, X will call XHelper right?"
Him: "Yes. and?"
Me: "So, if the helper is doing all the work it would make more sense to move it into X. if it doesn't, please give a more descriptive name"
Him: "But I don't have an X class!!!"
Me: "Even better! who are you helping?"