This question already has answers here:
Setting Objects to Null/Nothing after use in .NET
(15 answers)
Closed 8 years ago.
I don't mean to start a[nother] civil war over this issue, but should nullification be enforced or not?
While trying to fix a bug (that was fixed elsewise, as can be seen here), I added code like this in a couple of places to immediately and explicitly set some objects to null:
List<String> XMLFiles = CCRUtils.GetXMLFiles(fileType, #"\");
foreach (string fullXMLFilePath in XMLFiles)
{
RESTfulMethods.SendXMLFile(fullXMLFilePath, uri, 500);
}
XMLFiles = null;
Now that I know that did not solve the problem I was having, should I just leave it, or remove this type of code?
should nullification be enforced or not?
In general, it should not. There are very few circumstances where there is a reason to set a variable to null. As soon as the scope in which the variable is declared ends, the reference to the object will no longer be held.
Setting a variable to null after use is (almost) always just a misunderstanding of how the GC works, and serves no purpose.
Related
This question already has answers here:
What's the difference between passing by reference vs. passing by value?
(18 answers)
Closed 5 years ago.
I've been trying to understand passing by reference and passing by value and trying to understand it lead me to trying to understand reference data types. In all the explanations I've seen online they define a reference data type to be referencing data as opposed to containing data, and i'm wandering what is the difference?
What i think so far is that the variable doesn't contain data itself but it is referencing a method, but i don't feel like that is a satisfactory understanding. Hopefully someone could clear this up for me.
When you pass the reference of an variable, you are actually sending the memory address of that variable, whoever getting the address will be able to change your variable's value. but if you are passing by value, you are sending a copy of your variable, so even if the receiver changes the value of that variable, you will still get the original value of your variable.
This question already has answers here:
C# Empty Statement
(13 answers)
Closed 5 years ago.
I've come across this example of an empty statement in a C# textbook.
Code:
public void empty()
{
;
}
Some quick googling found that it's a redundant feature and I can't see the use of this as it seems pointless?
I was curious to know when this would've been useful and if it's still used to date even though it's obsolete?
In the given example it is pointless and/or cosmetic.
The empty statement is "useful" in places where a statement is required but you have nothing to do, like
while (condition_with_side_effects) ;
Because of the side effects required, this will not match with most coding guidelines or best practices.
Consider it a leftover from C.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I have a situation as below:
Some class
public class Numbers
{
}
Some other class
public class Calculations
{
Numbers objNumber = null;
public void abc()
{
objNumbers = new Numbers();
}
}
What is wrong with the statement Numbers objNumber = null;?
I know I could have simply ignored the null assignment; just curious why this is wrong.
It's not wrong, it's just unnecessary, all reference types are null by default, so there is no point on initializing the variable to null because the type of the variable is a reference type.
Reference types in c#, when declared are initialized automatically with null value. So there is no difference in
Numbers objNumbers = null;
and
Numbers objNumbers;
Both will work the same. You can check this behavior by using a debugging the code.
I don't see any issue with what you are doing, just additional note types are created with default value. It won't make any difference assigning null or ignoring it.
I see just there is a typo, which you could easily identify and fix it.
There is an extra s in objNumbers, the field is defined as objNumber.
The null will be the default value for the object(reference type). So It will be null even without the assignment by you. And there is nothing wrong with that statement.
In short
Numbers objNumbers = null; and Numbers objNumbers; are same.
Consider the following example;
Numbers objNumbers = new Numbers();
objNumbers = null;
Here assignment of null make Sense
Strictly speaking it is not wrong, as the code compiles (provided you add an s to your field name).
However, there are multiple reasons this code might be unreliable from a perspective of design or correctness.
You code has a mutable field not initialized to any meaningful value: Consider the possibility that the method abc() may not get called prior to the value stored at objNumbers being accessed, which will result in a null reference exception for any likely use case.
Now consider following the null object pattern and initializing the field to an instance of this null version of the Numbers class.
That code would be much less likely to produce a null reference exception... and it would force you to think about your application's behavior in the case where accessing the field occurs prior to the execution of method abc.
For both these reasons, in my opinion, it is a favorable design discipline to avoid initializing your fields/properties to null.
Additional reading on the topic, such as this thread, shows dealing with nulls is often considered a problem in need of a solution. Initializing your code with instances and values instead of null is a start in the right direction.
Don't think much. Even though you don't assign still all objects before allocating memory are null.
This question already has answers here:
Difference between null == x and x == null? [duplicate]
(5 answers)
Closed 9 years ago.
I have seen both
if(something == null)
and
if(null == something)
Does it make a difference in which order this null check happens? I do not see a difference in functionality but would love to know if there is reasoning behind it.
This is legal in C# and is colloquially known as a Yoda Condition. Many people in the C/C++ world like this because it guards at compile time against replacing == with = by accident. However, it has fallen out of favor in C# due to the fact the compiler will flag it (the single =) as an error in that instance (so long as it's not a boolean eval).
Some programmers prefer to put the constant on the left side of an equality operator to avoid accidents (a typo of = instead of ==). In the second example, having the = typo would introduce a compiler error, which is easy to fix, whereas in the first example such a typo may introduce a bug that is very difficult to find.
This practice comes directly out of C and C++ programming style. I don't know whether it would affect C#. If it's no longer relevant, then it's more likely to be a habit rather than a strategy.
This question already has answers here:
Why doesn't the C# compiler stop properties from referring to themselves?
(6 answers)
Closed 9 years ago.
Accidentally I created a bug in my work. The cause of the bug is a snippet of c# code like
public ClassA{
public string AProperty
{
get
{
return AProperty;
}
set
{
AProperty = value;
}
}
}
You can build that, and running that without any exceptions.
But it will create an infinite loop. For example, while setting the AProperty, it always tries to assign the value to its self.
Anyone knows why in C# the compiler will allow this syntax?
Because the C# compiler team didn't decide to make this exact case illegal. Possibly because they didn't consider the benefits of implementing it to be greater than the costs.
It's something that comes up with even the most trivial amount of testing; it's not a very subtle bug, and it's something that developers learn to look for if they get bitten by it a few times.