What this 'null' check doing here...
-
:doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh: :doh:
You owe me for the bandwidth cost of 2396 unnecessary :doh:s! Only the icon has 831 bytes, which amounts to a total of 1,991,076 wasted bytes. Gotta count now the extra html chars and send you the invoice! :doh: :sigh: :laugh:
-
List<Employee> employees = new List<Employee>();
if (employees != null){
employees = GetEmployees();
}Previous -> Read "CLR via C#" by Jeffrey Ritcher. Current -> Exploring WCF thru Apress' "Pro WCF" by Chris Peiris and Dennis Mulder. Next -> Need to read "The Art of Computer Programming" by Donald E. Knuth.
Probably code that has been edited and then not refactored. No real wtf here, ey?
-
Quote:
Is this inside a single method?
Yes, it is.
Quote:
I'd be more concerned here with the fact you'd never fill the employees list.
How??
Previous -> Read "CLR via C#" by Jeffrey Ritcher. Current -> Exploring WCF thru Apress' "Pro WCF" by Chris Peiris and Dennis Mulder. Next -> Need to read "The Art of Computer Programming" by Donald E. Knuth.
-
Keeping the runtime on its toes.
-
List<Employee> employees = new List<Employee>();
if (employees != null){
employees = GetEmployees();
}Previous -> Read "CLR via C#" by Jeffrey Ritcher. Current -> Exploring WCF thru Apress' "Pro WCF" by Chris Peiris and Dennis Mulder. Next -> Need to read "The Art of Computer Programming" by Donald E. Knuth.
Guess I don't know c# well enough, but I didn't this you could use any comparison operator against NULL. it's probably bad practice to even if the language allows it.
-
List<Employee> employees = new List<Employee>();
if (employees != null){
employees = GetEmployees();
}Previous -> Read "CLR via C#" by Jeffrey Ritcher. Current -> Exploring WCF thru Apress' "Pro WCF" by Chris Peiris and Dennis Mulder. Next -> Need to read "The Art of Computer Programming" by Donald E. Knuth.
Check your version control. It's possible declaration and/or the assignment at declaration was added later. If an earlier version of the method had the List passed as a parameter, then the test for non-null would make sense.
-
List<Employee> employees = new List<Employee>();
if (employees != null){
employees = GetEmployees();
}Previous -> Read "CLR via C#" by Jeffrey Ritcher. Current -> Exploring WCF thru Apress' "Pro WCF" by Chris Peiris and Dennis Mulder. Next -> Need to read "The Art of Computer Programming" by Donald E. Knuth.
I bet the person who wrote this comes from a C/C++ background, there, you have to check for null every time or you may blow out something...
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
List<Employee> employees = new List<Employee>();
if (employees != null){
employees = GetEmployees();
}Previous -> Read "CLR via C#" by Jeffrey Ritcher. Current -> Exploring WCF thru Apress' "Pro WCF" by Chris Peiris and Dennis Mulder. Next -> Need to read "The Art of Computer Programming" by Donald E. Knuth.
The only thing that I can think of is technically new doesn't guarantee that the variable initialization will take place. In programming languages like c++ it could return null. This could happen if the memory was so fragmented that the allocation failed. However, instead of returning null in C# I believe it throws a out of memory exception. I have only seen this done in system critical embedded systems.
-
List<Employee> employees = new List<Employee>();
if (employees != null){
employees = GetEmployees();
}Previous -> Read "CLR via C#" by Jeffrey Ritcher. Current -> Exploring WCF thru Apress' "Pro WCF" by Chris Peiris and Dennis Mulder. Next -> Need to read "The Art of Computer Programming" by Donald E. Knuth.
He is just double checking. :)
-
That's a real conundrum for the GC - "OK, if this object is still around, at this point, I can't GC it until then. But... but what if I ... secretlly GC it before the if?"
-
List<Employee> employees = new List<Employee>();
if (employees != null){
employees = GetEmployees();
}Previous -> Read "CLR via C#" by Jeffrey Ritcher. Current -> Exploring WCF thru Apress' "Pro WCF" by Chris Peiris and Dennis Mulder. Next -> Need to read "The Art of Computer Programming" by Donald E. Knuth.
Looks like a newbie whose prof in 101 programming hammered down checking objects before using them. This would be sensible if it were a thousand lines down in the code, but, if it is null where is the property/method to new it up?
-
Never mind - I've been up for the last 16 hours. I was reading != as == here for some reason. :doh:
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier -
Check your version control. It's possible declaration and/or the assignment at declaration was added later. If an earlier version of the method had the List passed as a parameter, then the test for non-null would make sense.
Quote:
It's possible declaration and/or the assignment at declaration was added later.
Ok but in the case if it is added later also, the guy should have removed the null check as it is not applicable now. Anyhow that wasn't the case, I checked the source control :)
Previous -> Read "CLR via C#" by Jeffrey Ritcher. Current -> Exploring WCF thru Apress' "Pro WCF" by Chris Peiris and Dennis Mulder. Next -> Need to read "The Art of Computer Programming" by Donald E. Knuth.
-
Probably code that has been edited and then not refactored. No real wtf here, ey?
But that's not the case I have verified the previous versions from source control...
Previous -> Read "CLR via C#" by Jeffrey Ritcher. Current -> Exploring WCF thru Apress' "Pro WCF" by Chris Peiris and Dennis Mulder. Next -> Need to read "The Art of Computer Programming" by Donald E. Knuth.
-
I bet the person who wrote this comes from a C/C++ background, there, you have to check for null every time or you may blow out something...
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
Correct. *** You're superb,,, What a guess!!! *** :thumbsup:
Previous -> Read "CLR via C#" by Jeffrey Ritcher. Current -> Exploring WCF thru Apress' "Pro WCF" by Chris Peiris and Dennis Mulder. Next -> Need to read "The Art of Computer Programming" by Donald E. Knuth.
-
The only thing that I can think of is technically new doesn't guarantee that the variable initialization will take place. In programming languages like c++ it could return null. This could happen if the memory was so fragmented that the allocation failed. However, instead of returning null in C# I believe it throws a out of memory exception. I have only seen this done in system critical embedded systems.
Thanks Michael. That was a excellent explanation.
Previous -> Read "CLR via C#" by Jeffrey Ritcher. Current -> Exploring WCF thru Apress' "Pro WCF" by Chris Peiris and Dennis Mulder. Next -> Need to read "The Art of Computer Programming" by Donald E. Knuth.
-
He is just double checking. :)
:laugh: The same thing I told him when I saw this first time. :)
Previous -> Read "CLR via C#" by Jeffrey Ritcher. Current -> Exploring WCF thru Apress' "Pro WCF" by Chris Peiris and Dennis Mulder. Next -> Need to read "The Art of Computer Programming" by Donald E. Knuth.
-
Looks like a newbie whose prof in 101 programming hammered down checking objects before using them. This would be sensible if it were a thousand lines down in the code, but, if it is null where is the property/method to new it up?
Well, he is 4 yrs exp.....
Previous -> Read "CLR via C#" by Jeffrey Ritcher. Current -> Exploring WCF thru Apress' "Pro WCF" by Chris Peiris and Dennis Mulder. Next -> Need to read "The Art of Computer Programming" by Donald E. Knuth.
-
:)
Previous -> Read "CLR via C#" by Jeffrey Ritcher. Current -> Exploring WCF thru Apress' "Pro WCF" by Chris Peiris and Dennis Mulder. Next -> Need to read "The Art of Computer Programming" by Donald E. Knuth.
-
It isn't really filling the list, it's replacing the reference with the result of that method call. I don't think that's what he meant though. A bit pedantic, I'm sorry.
I think the point was that
List employees = GetEmployees();could just as well have been used to create a null or non-null employees object because the if statement would never be false for a statement that could produce a null result. In fact you might want to execute
if (employees == null) throw...after executing the above line because now you are in a situation where the if statement could be true or false even if the current coding of the routine would never return null. (speaking of being pedantic...)