IsNullOrEmpty
-
A classic VB.Net mistake (I think somebody actually posted a variant recently), with a few extra goodies (copied verbatim from a class, StringAndText, a coworker wrote recently):
''' <summary>
''' Check if a string is null or empty
''' </summary>
''' <param name="str"></param>
''' <returns></returns>
Public Shared Function IsNullOrEmpty(ByVal str As String) As BooleanIf (str Is Nothing) OrElse (str = String.Empty) Then Return (True) End If Return (False)End Function
Have at it. :-D
Let's imagine that string.IsNullOrEmpty does not exist. Let's imagine that extension methods do not exist either. Let's imagine that a method like this might be useful. With all of these premises, I still think that someone should invent a computer which slapped anyone who wrote an "If" statement just to return the result of the condition evaluated by that "If". I have seen it countless times, and I still don't understand how they do not notice it.
-
Let's imagine that string.IsNullOrEmpty does not exist. Let's imagine that extension methods do not exist either. Let's imagine that a method like this might be useful. With all of these premises, I still think that someone should invent a computer which slapped anyone who wrote an "If" statement just to return the result of the condition evaluated by that "If". I have seen it countless times, and I still don't understand how they do not notice it.
If string.IsNullOrEmpty did not exist, I would create it in my source because it is a heavily used utility function, even if the the method only returns the results of an "if" evaluation. My reasoning for this is that the usage of stringVariable.IsNullOrEmpty() is very clear as to what is being evaluated while if( stringVariable == null || stringVariable.Length == 0 ) is not as clear. From a sustainability standpoint I would definitely create it. As a note, I always add this utility to all solutions that do not have the support natively.
I wasn't, now I am, then I won't be anymore.
-
If string.IsNullOrEmpty did not exist, I would create it in my source because it is a heavily used utility function, even if the the method only returns the results of an "if" evaluation. My reasoning for this is that the usage of stringVariable.IsNullOrEmpty() is very clear as to what is being evaluated while if( stringVariable == null || stringVariable.Length == 0 ) is not as clear. From a sustainability standpoint I would definitely create it. As a note, I always add this utility to all solutions that do not have the support natively.
I wasn't, now I am, then I won't be anymore.
Yes, sure, but what I meant was more about the implementation itself:
public static bool IsNullOrEmpty(string str)
{
return str == null || str == "";
}No need of an "if" statement since we are actually returning the result of the condition itself. This is what I meant.
-
Yes, sure, but what I meant was more about the implementation itself:
public static bool IsNullOrEmpty(string str)
{
return str == null || str == "";
}No need of an "if" statement since we are actually returning the result of the condition itself. This is what I meant.
But do you want to write the entire "if" statement in hundreds of places in a large solution, or one that can be issued a test-case for coverage and validation that will then be validated from intellisense. Any equality statement is dangerous in the old "str = null" vs "str == null" world and thus should be encapsulated into a testable case.
I wasn't, now I am, then I won't be anymore.
-
But do you want to write the entire "if" statement in hundreds of places in a large solution, or one that can be issued a test-case for coverage and validation that will then be validated from intellisense. Any equality statement is dangerous in the old "str = null" vs "str == null" world and thus should be encapsulated into a testable case.
I wasn't, now I am, then I won't be anymore.
Marcus Kramer wrote:
But do you want to write the entire "if" statement in hundreds of places in a large solution, or one that can be issued a test-case for coverage and validation that will then be validated from intellisense. Any equality statement is dangerous in the old "str = null" vs "str == null" world and thus should be encapsulated into a testable case.
Uh, what? Are you saying that the if statement should be encapsulated in a method rather than sprinkling the if statement over several places in the code? Erik never said otherwise. He just said that rather than using an if statement, a single return statement can be used (yes, inside a method).
-
Marcus Kramer wrote:
But do you want to write the entire "if" statement in hundreds of places in a large solution, or one that can be issued a test-case for coverage and validation that will then be validated from intellisense. Any equality statement is dangerous in the old "str = null" vs "str == null" world and thus should be encapsulated into a testable case.
Uh, what? Are you saying that the if statement should be encapsulated in a method rather than sprinkling the if statement over several places in the code? Erik never said otherwise. He just said that rather than using an if statement, a single return statement can be used (yes, inside a method).
I stand corrected. I misread that last post from Erik.... :doh:
I wasn't, now I am, then I won't be anymore.
-
I fail to see the great horror in your code... If you are posting in the Hall of Shame with a code snippet, should there not be at least one subtle horror in there? We are coming here to be amused, not educated... (Nicely explained, by the way. I actually ran into a few senior developers in my time who did not understand this concept)
I wasn't, now I am, then I won't be anymore.
Indeed, I'm in a VB shop now and it seems that someone thinks reference types always have be passed
byref. :sigh: -
Yes, sure, but what I meant was more about the implementation itself:
public static bool IsNullOrEmpty(string str)
{
return str == null || str == "";
}No need of an "if" statement since we are actually returning the result of the condition itself. This is what I meant.
Yes, but... make a generic one that takes any IList as well. (Oh how I wish String implemented IList. :sigh: ) (And don't compare to an empty string[^].)
-
Indeed, I'm in a VB shop now and it seems that someone thinks reference types always have be passed
byref. :sigh:Ain't that the truth... Ironically, I have a couple QA's who I'm mentoring in C# for web automation testing that have a better grasp... They have never taken any courses... (They also write better code, but I'll pretend that is because of me)
I wasn't, now I am, then I won't be anymore.
-
Yes, but... make a generic one that takes any IList as well. (Oh how I wish String implemented IList. :sigh: ) (And don't compare to an empty string[^].)
-
I can't see the problem...
return lst == null || lst.Count == 0;
Becouse if a class implements IList it must also implement ICollection.
Yes, but String isn't an IList -- but not to worry, I wrote... I wrote my own String class today. :cool: