We Keep Coding

How to remove compiler error with struct: "Use of unassigned local variable"

The C# compiler is a bit ... old fashioned ... and won't do static analysis. So it breaks on seemingly correct code like this:
MyStruct s;
bool inited = false;
foreach( Something foo in ACollection )
{
if( foo.Test() )
continue;
if( inited )
s.DoSomething();
else
{
s = foo.GetMeAnS();
inited = true;
}
}
Note: the unusual problem is that "s" is a struct. If it were a class, I'd simply init it to null. This struct has no meaningful "uninited" state, and I don't want to pay the performance cost of initing something I immediately throw away, just to satisfy a weak compiler.
The code (should be) fully correct: it's impossible to access s until s has been inited. (I've copy/pasted from actual code, but edited-out long method names for simplicity).
C# compiler in Mono used to allow this, but now it doesn't. Nothing has changed except the compiler, which now gives an error on unassigned variable.
Is there a code way to tell it to shut up and mind its own business? :) I don't want to fiddle with changing compiler-settings (if possible) because the code is compiled by other people/orgs - I'd prefer a code way of fixing the problem.

Is there a code way to tell it to shut up and mind its own business?
The compiler's business is implementing the C# specification. The code you've written should not compile according to the C# specification. The s.DoSomething() call is reachable without s being definitely assigned, therefore your code is broken. That's not the compiler's fault. If the Mono compiler used to allow it, that was a bug which has apparently now been fixed.
The simplest way of fixing it is to definitely assign the value, of course:
MyStruct s = new MyStruct(); // Value will never actually be used
There are plenty of cases where we (as humans) can tell that something will never happen, but the compiler can't. Here's another example:
public int Foo(int input)
{
if (input >= 0)
{
return input;
}
else if (input < 0)
{
return -input;
}
// This is still reachable...
}
We know that every int input will go into one of those if bodies, but the compiler will still (correctly) give a compilation error on the above code, because the closing brace is reachable and it's a non-void method.
Your claim that "The code (should be) fully correct" is according to your reasoning, not the C# specificiation... and the compiler is only meant to care about the latter.
One thing to note: the specification doesn't even care about the fact that we do actually set inited to true in some cases. Even if it always had the value of false, it's still just a local variable, not a constant expression. Here's a simple example demonstrating that with no loop:
static void Main()
{
int x;
bool condition = false;
if (condition)
{
Console.WriteLine(x);
}
}
This still gives an error: "error CS0165: Use of unassigned local variable 'x'"
From section 8.7.1 of the C# 5 specification:
The first embedded statement of an if statement is reachable if the if statement is reachable and the boolean expression does not have the constant value false.
Here the expression is condition, which is a local variable. A local variable is not a constant expression in technical terms, even if it will never change. If you make it a local constant instead, it will compile:
static void Main()
{
int x;
const bool condition = false;
if (condition)
{
Console.WriteLine(x);
}
}
Now there's a warning about the body of the if statement being unreachable - but there's no error.

The C# specification was designed such that you should never be able to use an uninitialized variable. This is not an old fashioned concept. The old fashioned way to deal with this (in C++) was to say, "This is undefined behaviour, anything can happen".
Strangely enough lots of bugs were caused by this attitude, which gave rise to many compilers automagically initing (in debug mode) variables into such gems as 0xDEADBEEF.
As for why the C# compiler doesn't do code analysis to find if the variable is inited when it reaches that code?
Halting Problem
The problem could be rewritten like this.
bool inited = false;
MyStruct? s;
while (true)
{
foreach( Something foo in ACollection )
foo.Test();
if( inited && false == s.HasValue )
return;
}
This is only slightly changed code. But you can see, I have converted your problem into the Halting Problem, where the inputs are, the state of each Something and the implementation of foo.Test().
This is proven to be undecidable on a Turing Machine, which your CLR VM certainly is.
In short, you are asking, why hasn't microsoft broken the laws of Mathematics and Computer Science when they wrote the C# compiler.
Or you are asking, shouldn't the Microsoft C# Compiler try hard before giving up on the Halting Problem. To which my response is, how hard should they try?

Why i can't use the iteration variable from a for outside this [duplicate]

This question already has answers here:
C# variable scoping: 'x' cannot be declared in this scope because it would give a different meaning to 'x'
(3 answers)
Closed 8 years ago.
I've been wondering why in C# using a variable name used previously in a child scope is not allowed. Like this:
if (true)
{
int i = 1;
}
int i = 2;
Compiling the above code produces an error:
A local variable named 'i' cannot be
declared in this scope because it
would give a different meaning to 'i',
which is already used in a 'child'
scope to denote something else
And yet you can't use the variable defined in child scope either. The code above works just fine in Java and I can see no reason why it doesn't in C# too. I'm sure there's a good reason, but what is it?

It is a design choice made by the designers of C#. It reduces potential ambiguity.
You can use it in one of the two places, inside the if or outside, but you can only define it in one place. Otherwise, you get a compiler error, as you found.

Something I noticed that was not noted here. This will compile:
for (int i = 0; i < 10; i++)
{
int a = i * 2;
}
for (int i = 0; i < 5; i++)
{
int b = i * 2;
}
Taken together, these design decisions seem inconsistent, or at least oddly restrictive and permissive, respectively.

As Adam Crossland said, it's a design choice - Made to make sure you (or more likely, your fellow developers) dont misunderstand the code.
You often see private instance members prefixed with a "m_" or "_" (eg. _myVar or m_myVar) to avoid confusion..

to all probability, any variable created in any of the child scope, will be put on the stackframe the moment method is entered.
This way, a similar name in a child scope can not co-exist with a variable name in another child scope.
They could have worked around this of course if they wanted, so I guess it ultimately has to do with design as well.. this way there is less chance for error

Readability a=b=c or a=c; b=c;?

I have a class which has a group of integers, say
foo()
{
int a;
int b;
int c;
int d;
....
string s;
}
Now the question is for the best readbility, the init() function for foo(), should it look like
void init()
{
a=b=c=d=1; //for some reason they are init to 1;
s = "abc";
}
or
void init()
{
a=1;
b=1;
c=1;
d=1;
s = "abc";
}
?
The reason for a string in class is a hint of other groups of same types might present and of course, the class might grow as requirement changes
EDIT: before this question goes too far, the intention of this question was simple:
In Effective C++ item 12 (prefer initialization to assignment in constructors), Scott uses chain assignment instead of a=c; b=c; I am sure he knows when to use what, but I also remembered the books I read also recommended to use int a; int b; which in similar case of assignments. In my program I have a similar situation of a group of related individual build-in types needs to be initialized and I have found by making a chain assignment does makes it easier to read especially if the class have many other different types instance variables. It seems to contradict with books I read and my memory, hence the question.

I happen to prefer the chained version, but it's completely a matter of preference.
Please note, however, that
a = b = c = 0;
is equivalent to:
c = 0;
b = c;
a = b;
and not
a = 0;
b = 0;
c = 0;
(not that it should matter to you which assignment happens first)

My personal preference is a=b=c=d for the following reasons:
It is concise, saves lines
It conveys the concept that (a/b/c/d) are initialized to the same thing, that they are related
However, caveat:
Don't do that if a/b/c/d are not related (and just happens to be initialized to 1). You'll reduce the readability of your code. Example:
a=c=1; // Foo-function related
b=d=1; // Bar-function related
Chaining assignments like this reduces the flexibility for you in the future to assign different initial values to the variables -- because then you'll have to break them up again.
Nevertheless, my personal recommendation is to chain assignments on variables that are related on concept/usage. In actual practice, the need to change an assignment usually doesn't come up often so caveat #2 should not typically pose a problem.
Edit: My recommendation may go against published guidelines. See the comments.

I guess it is a matter of opinion which is most readable. (Clearly so ... otherwise you wouldn't be asking.)
However Oracle's "Code Conventions for the Java TM Programming Language" clearly says to use separate assignment statements:
10.4 Variable Assignments. "Avoid assigning several variables to the same value in a single statement. It is hard to read."
My opinion?
Follow your project's prescribed / agreed style rules, even if you don't like them1.
If your project doesn't (yet) have prescribed / agreed style rules:
Try to persuade the other members to adopt the most widely used applicable style rules.
If you can't persuade them / come to a consensus, then just do this informally for the major chunks of code that you write for the project1.
1 ... or get out.

why in c# we need to initialize primitive type variable? [duplicate]

This question already has answers here:
Initialization of instance fields vs. local variables
(7 answers)
Closed 6 years ago.
why in c# we need to initialize primitive type variable --
static void Main(string[] args)
{
int a;
Console.WriteLine(a);
}
throws compile time error ...

In order to prevent potential coding mistakes, C# will not allow you to use any local variable until the compiler can prove that it has been initialized.

Purely because it is a good practice. CLR initialize them to defaults anyway - for ValueTypes.

its because of inference feature....
c # does type cast variable static unlike dynamic in python pearl
so by checking type of values by which your variable is initialized
type of variable is decided and verified.
its done at compile time

There's another conceptual reason.
Everything in .NET is an object.
Variables are holders, which can hold references to objects or they can point to values.
Why C# should be able to let you output to Console (as in your example) a variable which holds nothing?
For me the question is, don't you find useful C# compiler preventing you from creating useless code? Any help is always useful in terms of avoiding human mistakes or wrong logic.
Maybe I should believe you say that because...
int a;
if(false) { a = 1; }
Console.WriteLine(a);
...won't compile too.
Well, why C# compiler should allow you to work with a reference to nothing? Any argument would be weak since what good program should write to console nothing? If your program doesn't need to print, just don't print.
For example, if you want to do it right, it should be:
int a;
if(false) { a = 1; } else { a = 0; }
Console.WriteLine(a);
"I want my program to show 1 if it's false, or 0 if it's true". But "show 1 if it's false, or show 'I don't know what'" is a weak argument.
It's like saying "do you want apples or emptiness?".

When should one try to eliminate a switch statement? [duplicate]

This question already has answers here:
Is Switch (Case) always wrong?
(8 answers)
Closed 9 years ago.
I've come across a switch statement in the codebase I'm working on and I'm trying to figure out how to replace it with something better since switch statements are considered a code smell. However, having read through several posts on stackoverflow about replacing switch statements I can't seem to think of an effective way to replace this particular switch statement.
Its left me wondering if this particular switch statement is ok and if there are particular circumstances where switch statements are considered appropriate.
In my case the code (slightly obfuscated naturally) that I'm struggling with is like this:
private MyType DoSomething(IDataRecord reader)
{
var p = new MyType
{
Id = (int)reader[idIndex],
Name = (string)reader[nameIndex]
}
switch ((string) reader[discountTypeIndex])
{
case "A":
p.DiscountType = DiscountType.Discountable;
break;
case "B":
p.DiscountType = DiscountType.Loss;
break;
case "O":
p.DiscountType = DiscountType.Other;
break;
}
return p;
}
Can anyone suggest a way to eliminate this switch? Or is this an appropriate use of a switch? And if it is, are there other appropriate uses for switch statements? I'd really like to know where they are appropriate so I don't waste too much time trying to eliminate every switch statement I come across just because they are considered a smell in some circumstances.
Update: At the suggestion of Michael I did a bit of searching for duplication of this logic and discovered that someone had created logic in another class that effectively made the whole switch statement redundant. So in the context of this particular bit of code the switch statement was unnecessary. However, my question is more about the appropriateness of switch statements in code and whether we should always try to replace them whenever they are found so in this case I'm inclined to accept the answer that this switch statement is appropriate.

This is an appropriate use for a switch statment, as it makes the choices readable, and easy to add or subtract one.
See this link.

Switch statements (especially long ones) are considered bad, not because they are switch statements, but because their presence suggests a need to refactor.
The problem with switch statements is they create a bifurcation in your code (just like an if statement does). Each branch must be tested individually, and each branch within each branch and... well, you get the idea.
That said, the following article has some good practices on using switch statements:
http://elegantcode.com/2009/01/10/refactoring-a-switch-statement/
In the case of your code, the article in the above link suggests that, if you're performing this type of conversion from one enumeration to another, you should put your switch in its own method, and use return statements instead of the break statements. I've done this before, and the code looks much cleaner:
private DiscountType GetDiscountType(string discount)
{
switch (discount)
{
case "A": return DiscountType.Discountable;
case "B": return DiscountType.Loss;
case "O": return DiscountType.Other;
}
}

I think changing code for the sake of changing code is not best use of ones time. Changing code to make it [ more readable, faster, more efficient, etc, etc] makes sense. Don't change it merely because someone says you're doing something 'smelly'.
-Rick

This switch statement is fine. Do you guys not have any other bugs to attend to? lol
However, there is one thing I noticed... You shouldn't be using index ordinals on the IReader[] object indexer.... what if the column orders change? Try using field names i.e. reader["id"] and reader["name"]

In my opinion, it's not switch statements that are the smell, it's what's inside them. This switch statement is ok, to me, until it starts adding a couple of more cases. Then it may be worth creating a lookup table:
private static Dictionary<string, DiscountType> DiscountTypeLookup =
new Dictionary<string, DiscountType>(StringComparer.Ordinal)
{
{"A", DiscountType.Discountable},
{"B", DiscountType.Loss},
{"O", DiscountType.Other},
};
Depending on your point-of-view, this may be more or less readable.
Where things start getting smelly is if the contents of your case are more than a line or two.

Robert Harvey and Talljoe have provided excellent answers - what you have here is a mapping from a character code to an enumerated value. This is best expressed as a mapping where the details of the mapping are provided in one place, either in a map (as Talljoe suggests) or in a function that uses a switch statement (as suggested by Robert Harvey).
Both of those techniques are probably fine in this case, but I'd like to draw your attention to a design principal that may be useful here or in other similar cases. The the Open/Closed principal:
http://en.wikipedia.org/wiki/Open/closed_principle
http://www.objectmentor.com/resources/articles/ocp.pdf (make sure you read this!)
If the mapping is likely to change over time, or possibly be extended runtime (eg, through a plugin system or by reading the parts of the mapping from a database), then a using the Registry Pattern will help you adhere to the open/closed principal, in effect allowing the mapping to be extended without affecting any code that uses the mapping (as they say - open for extension, closed for modification).
I think this is a nice article on the Registry Pattern - see how the registry holds a mapping from some key to some value? In that way it's similar to your mapping expressed as a switch statement. Of course, in your case you will not be registering objects that all implement a common interface, but you should get the gist:
http://sinnema313.wordpress.com/2009/03/01/the-registry-pattern/
So, to answer the original question - the case statement is poor form as I expect the mapping from the character code to an enumerated value will be needed in multiple places in your application, so it should be factored out. The two answers I referenced give you good advice on how to do that - take your pick as to which you prefer. If, however, the mapping is likely to change over time, consider the Registry Pattern as a way insulating your code from the effects of such change.

I wouldn't use an if. An if would be less clear than the switch. The switch is telling me that you are comparing the same thing throughout.
Just to scare people, this is less clear than your code:
if (string) reader[discountTypeIndex]) == "A")
p.DiscountType = DiscountType.Discountable;
else if (string) reader[discountTypeIndex]) == "B")
p.DiscountType = DiscountType.Loss;
else if (string) reader[discountTypeIndex]) == "O")
p.DiscountType = DiscountType.Other;
This switch may be OK, you might want to look at #Talljoe suggestion.

Are switches on discount type located throughout your code? Would adding a new discount type require you to modify several such switches? If so you should look into factoring the switch out. If not, using a switch here should be safe.
If there is a lot of discount specific behavior spread throughout your program, you might want to refactor this like:
p.Discount = DiscountFactory.Create(reader[discountTypeIndex]);
Then the discount object contains all the attributes and methods related to figuring out discounts.

You are right to suspect this switch statement: any switch statement that is contingent on the type of something may be indicative of missing polymorphism (or missing subclasses).
TallJoe's dictionary is a good approach, however.
Note that if your enum and database values were integers instead of strings, or if your database values were the same as the enum names, then reflection would work, e.g. given
public enum DiscountType : int
{
Unknown = 0,
Discountable = 1,
Loss = 2,
Other = 3
}
then
p.DiscountType = Enum.Parse(typeof(DiscountType),
(string)reader[discountTypeIndex]));
would suffice.

Yes, this looks like a correct usage of switch statement.
However, I have another question for you.
Why haven't you included the default label? Throwing an Exception in the default label will make sure that the program will fail properly when you add a new discountTypeIndex and forget to modify the code.
Also, if you wanted to map a string value to an Enum, you can use Attributes and reflection.
Something like:
public enum DiscountType
{
None,
[Description("A")]
Discountable,
[Description("B")]
Loss,
[Description("O")]
Other
}
public GetDiscountType(string discountTypeIndex)
{
foreach(DiscountType type in Enum.GetValues(typeof(DiscountType))
{
//Implementing GetDescription should be easy. Search on Google.
if(string.compare(discountTypeIndex, GetDescription(type))==0)
return type;
}
throw new ArgumentException("DiscountTypeIndex " + discountTypeIndex + " is not valid.");
}

I think this depends if you are creating MType add many different places or only at this place. If you are creating MType at many places always having to switch for the dicsount type of have some other checks then this could be a code smell.
I would try to get the creation of MTypes in one single spot in your program maybe in the constructor of the MType itself or in some kind of factory method but having random parts of your program assign values could lead to somebody not knowing how the values should be and doing something wrong.
So the switch is good but maybe the switch needs to be moved more inside the creation part of your Type

I'm not absolutely opposed to switch statements, but in the case you present, I'd have at least eliminated the duplication of assigning the DiscountType; I might have instead written a function that returns a DiscountType given a string. That function could have simply had the return statements for each case, eliminating the need for a break. I find the need for breaks between switch cases very treacherous.
private MyType DoSomething(IDataRecord reader)
{
var p = new MyType
{
Id = (int)reader[idIndex],
Name = (string)reader[nameIndex]
}
p.DiscountType = FindDiscountType(reader[discountTypeIndex]);
return p;
}
private DiscountType FindDiscountType (string key) {
switch ((string) reader[discountTypeIndex])
{
case "A":
return DiscountType.Discountable;
case "B":
return DiscountType.Loss;
case "O":
return DiscountType.Other;
}
// handle the default case as appropriate
}
Pretty soon, I'd have noticed that FindDiscountType() really belongs to the DiscountType class and moved the function.

When you design a language and finally have a chance to remove the ugliest, most non-intuitive error prone syntax in the whole language.
THAT is when you try and remove a switch statement.
Just to be clear, I mean the syntax. This is something taken from C/C++ which should have been changed to conform with the more modern syntax in C#. I wholeheartedly agree with the concept of providing the switch so the compiler can optimise the jump.