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
Mmm! I love the smell of unnecessary string creation in the morning!
ByValon an unnecessary function just to make it less efficient than the built in version... [edit]Griff, you are an idiot - OriginalGriff[/edit]Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
modified on Friday, December 31, 2010 3:01 AM
-
Mmm! I love the smell of unnecessary string creation in the morning!
ByValon an unnecessary function just to make it less efficient than the built in version... [edit]Griff, you are an idiot - OriginalGriff[/edit]Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
modified on Friday, December 31, 2010 3:01 AM
For shame! String is a class and all class instances get their references passed around (so there is no large copy when using ByVal). When you do ByRef, you actually pass a reference to that reference, allowing the source variable (used by the caller) to be assigned something different. Take this for example:
Public Class Form1
Private small As String = "a" Private large As String = "This was a really long string I shortened so I could paste it here easily..." Private Const MAX As Integer = 9999999 Private startTime As DateTime Private endTime As DateTime Private smallDuration As Integer Private largeDuration As Integer Dim sb As System.Text.StringBuilder Private Sub Button1\_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click sb = New System.Text.StringBuilder() GC.Collect() GC.WaitForPendingFinalizers() startTime = DateTime.Now For i As Integer = 0 To MAX sb.Append(FirstChar(large)) Next endTime = DateTime.Now largeDuration = CInt(endTime.Subtract(startTime).TotalMilliseconds) sb = New System.Text.StringBuilder() GC.Collect() GC.WaitForPendingFinalizers() startTime = DateTime.Now For i As Integer = 0 To MAX sb.Append(FirstChar(small)) Next endTime = DateTime.Now smallDuration = CInt(endTime.Subtract(startTime).TotalMilliseconds) MessageBox.Show(String.Format("Small: {0}, Large: {1}", smallDuration.ToString(), largeDuration.ToString())) End Sub ' TODO: Try ByRef and ByVal, and compare them. Private Function FirstChar(ByRef str As String) As String Return str.Substring(0, 1) End FunctionEnd Class
The timings in that example will always be very similar, whether you use a large string, a small string, ByRef, or ByVal. Using ByRef when you don't actually intend to treat that variable as an output from the function would be a coding horror! But don't stop there. There are plenty more horrors in the IsNullOrEmpty function. :)
-
For shame! String is a class and all class instances get their references passed around (so there is no large copy when using ByVal). When you do ByRef, you actually pass a reference to that reference, allowing the source variable (used by the caller) to be assigned something different. Take this for example:
Public Class Form1
Private small As String = "a" Private large As String = "This was a really long string I shortened so I could paste it here easily..." Private Const MAX As Integer = 9999999 Private startTime As DateTime Private endTime As DateTime Private smallDuration As Integer Private largeDuration As Integer Dim sb As System.Text.StringBuilder Private Sub Button1\_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click sb = New System.Text.StringBuilder() GC.Collect() GC.WaitForPendingFinalizers() startTime = DateTime.Now For i As Integer = 0 To MAX sb.Append(FirstChar(large)) Next endTime = DateTime.Now largeDuration = CInt(endTime.Subtract(startTime).TotalMilliseconds) sb = New System.Text.StringBuilder() GC.Collect() GC.WaitForPendingFinalizers() startTime = DateTime.Now For i As Integer = 0 To MAX sb.Append(FirstChar(small)) Next endTime = DateTime.Now smallDuration = CInt(endTime.Subtract(startTime).TotalMilliseconds) MessageBox.Show(String.Format("Small: {0}, Large: {1}", smallDuration.ToString(), largeDuration.ToString())) End Sub ' TODO: Try ByRef and ByVal, and compare them. Private Function FirstChar(ByRef str As String) As String Return str.Substring(0, 1) End FunctionEnd Class
The timings in that example will always be very similar, whether you use a large string, a small string, ByRef, or ByVal. Using ByRef when you don't actually intend to treat that variable as an output from the function would be a coding horror! But don't stop there. There are plenty more horrors in the IsNullOrEmpty function. :)
:-O You are right, I can only plead stupidity and not bothering to think before I commented!
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
-
For shame! String is a class and all class instances get their references passed around (so there is no large copy when using ByVal). When you do ByRef, you actually pass a reference to that reference, allowing the source variable (used by the caller) to be assigned something different. Take this for example:
Public Class Form1
Private small As String = "a" Private large As String = "This was a really long string I shortened so I could paste it here easily..." Private Const MAX As Integer = 9999999 Private startTime As DateTime Private endTime As DateTime Private smallDuration As Integer Private largeDuration As Integer Dim sb As System.Text.StringBuilder Private Sub Button1\_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click sb = New System.Text.StringBuilder() GC.Collect() GC.WaitForPendingFinalizers() startTime = DateTime.Now For i As Integer = 0 To MAX sb.Append(FirstChar(large)) Next endTime = DateTime.Now largeDuration = CInt(endTime.Subtract(startTime).TotalMilliseconds) sb = New System.Text.StringBuilder() GC.Collect() GC.WaitForPendingFinalizers() startTime = DateTime.Now For i As Integer = 0 To MAX sb.Append(FirstChar(small)) Next endTime = DateTime.Now smallDuration = CInt(endTime.Subtract(startTime).TotalMilliseconds) MessageBox.Show(String.Format("Small: {0}, Large: {1}", smallDuration.ToString(), largeDuration.ToString())) End Sub ' TODO: Try ByRef and ByVal, and compare them. Private Function FirstChar(ByRef str As String) As String Return str.Substring(0, 1) End FunctionEnd Class
The timings in that example will always be very similar, whether you use a large string, a small string, ByRef, or ByVal. Using ByRef when you don't actually intend to treat that variable as an output from the function would be a coding horror! But don't stop there. There are plenty more horrors in the IsNullOrEmpty function. :)
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.
-
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:
