9
\$\begingroup\$

I have some static helper class:

public static class Helper
{
    public static bool IsNull<T>(this T value) where T : class
    {
        return (value == null);
    }

    public static bool NotNull<T>(this T value) where T : class
    {
        return (!value.IsNull<T>());
    }

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

    public static bool NotNullAndNotEmpty(this string value)
    {
        return (!value.IsNullOrEmpty());
    }

    public static bool NotNullAndNotEmpty(this ICollection value)
    {
        return (value.NotNull<ICollection>() && (value.Count > 0));
    }

    public static bool IsNullOrEmpty(this ICollection value)
    {
        return (!value.NotNullAndNotEmpty());
    }
}

It is comfortable (habit) for me to use this helper, but I am not sure that it is correctly (worth it). How about performance? Are there any other reasons to not use it?

\$\endgroup\$
10
  • \$\begingroup\$ Isn't IsNullOrEmpty just replacing the same exact extension? \$\endgroup\$
    – Fuji
    Dec 7, 2011 at 14:27
  • \$\begingroup\$ I don't see any problems with this code. \$\endgroup\$
    – kol
    Dec 7, 2011 at 14:28
  • 1
    \$\begingroup\$ Perf is a non-issue. Having somebody else read your code and have no clue why it works is an issue. These extension methods look like instance methods in the code, seeing them being use on null objects is a nasty speed-bump. That extension methods support a null object is frankly a bit of a bug, not a feature, given that this is so very unlike the way the rest of the language works. But I'm sure you'll disagree :) \$\endgroup\$
    – Hans Passant
    Dec 7, 2011 at 14:29
  • \$\begingroup\$ @Fuji String.IsNullOrEmpty is static. Helper.IsNullOrEmpty can be called as if it was a non-static method. \$\endgroup\$
    – kol
    Dec 7, 2011 at 14:29
  • \$\begingroup\$ @kol and yet, it is still a static method, in every sense, really. \$\endgroup\$
    – Andrew Barber
    Dec 7, 2011 at 14:34

2 Answers 2

10
\$\begingroup\$

This gets to be a sticky point. There are those who will argue fervently that an extension method should never work on a null reference, and there are those who are fine with that.

Personally, I don't mind extension methods on null if the name is a clear indicator that null is a possibility (like IsNullOrEmpty) but as I said, that's my opinion and may not match others.

Don't worry about the performance, method calls are not a serious impact and check methods like this eliminate some of the readability concerns over compound expressions when maintaining the code. After all, that's what string.IsNullOrEmpty() does, but it does it through a static method instead of an extension method.

So the only concern, really, you may get push back that these are extension methods as opposed to ordinary static methods, but you'll get differing opinions on whether calling an extension method on null is bad/okay.

One could argue Microsoft disallows LINQ extension methods on null sequences, but then again Microsoft also doesn't disallow extension method calls on a null source in general.

So, the choice is yours, I don't have an issue with them since the names clearly indicate null is an accepted possibility, but I can see both sides of the argument.

On a side note, I'd keep your naming consistent:

  • NotNull -> IsNotNull
  • NotNullAndNotEmpty -> IsNotNullAndNotEmpty
\$\endgroup\$
7
  • \$\begingroup\$ I'd really like to see someone's argument on why it is fundamentally wrong to have an extension method for potentially null values. \$\endgroup\$
    – oscilatingcretin
    Dec 7, 2011 at 15:01
  • \$\begingroup\$ @oscilatingcretin: I think the main concern is that extension methods are designed to look like instance methods, but in that particular aspect they differ from instance methods, thus it could be misleading as a maintenance/readability issue. I'm not saying that's a reason not to do it, but you do get that argument a lot. \$\endgroup\$
    – James Michael Hare
    Dec 7, 2011 at 15:04
  • \$\begingroup\$ But an instance method can still be called when the object is null. Either way, you get a null reference exception regardless wehether or not it is an instance method or extension method. Maybe I am not grasping the merits of the argument. \$\endgroup\$
    – oscilatingcretin
    Dec 7, 2011 at 15:10
  • \$\begingroup\$ Welcome :) value.NotNull() extension method cannot be used in Linq2Sql: ...Where(i => (i != null)) => works ok, ...Where(i => i.NotNull()) => occurs run-time exception. \$\endgroup\$
    – Maxim Polishchuk
    Dec 7, 2011 at 15:10
  • \$\begingroup\$ @oscilatingcretin: Not necessarily, there's nothing that says your extension method can't handle null (like his does), but an instance method can never handle null was my main point. Also, an extension method should never directly throw a NullReferenceException, that's a system exception that only the CLR should throw. Unless you meant indirectly by dereferencing, then sure! \$\endgroup\$
    – James Michael Hare
    Dec 7, 2011 at 15:13
0
\$\begingroup\$

I don't see exactly what's the win for you with this helper class. Most of the methods you have shown seem like some overhead. For example:

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

Although it will provide you a fluent syntax in your code. Performance will not bite you, your not doing very heavy things inside your extension methods.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ It can be called as if it was a non-static method: s.IsNullOrEmpty(). I guess he prefers this format over string.IsNullOrEmpty(s). \$\endgroup\$
    – kol
    Dec 7, 2011 at 14:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.