scope of List<Queue> different?

[roady001]

I commented the following: Look at the 'THIS FAILS, WHY?' line at SetValue(), why does it fail? The error message is that the object is null (NullReferenceException), however the constructor is correct isn't it? I tested it with the someInteger variable, and everything is ok there...

Thanks for any reply!

public class MyClass
{
private List<Queue> listOfItems;
private int someInteger;

public MyClass()
{
List<Queue> listOfItems = new List<Queue>();
listOfItems.Add(new Queue()); // THIS WORKS
someInteger = 0; // THIS WORKS
}

public void SetValue()
{
someInteger = 1; // THIS WORKS
listOfItems.Add(new Queue()); // THIS FAILS, WHY?!?
}

}

[nelo]

1. Use code tags.

2. You have declare a 'class' wide variable called 'listOfItems' which you are using in 'SetValue' method. That 'listOfItems' has not been instantiated hence the null reference exception. The problem is not 'new Queue()' it is that listOfItems is null. My suggestion would be to initialise it when you declare it. Or initialise it in a constructor. By the way in your construction you've declared a local variable (and initialised it) of the same name. Was that intentional?

[roady001]

Thanks, your 'By the way' did it. No, it was not my intention to declared a local variable, because it had to be kept class-wide. I goofed it up there!

This is how it should have been in the first place, and now it's working.


public class MyClass
{


private List<Queue> listOfItems;
private int someInteger;



public MyClass()
{
listOfItems = new List<Queue>();
listOfItems.Add(new Queue()); // THIS WORKS
someInteger = 0; // THIS WORKS
}

public void SetValue()
{
someInteger = 1; // THIS WORKS
listOfItems.Add(new Queue()); // NOW IT WORKS!
}

}

[nelo]

Thanks, your 'By the way' did it. No, it was not my intention to declared a local variable, because it had to be kept class-wide. I goofed it up there!

This is how it should have been in the first place, and now it's working.

All's well that ends well! It happens to a lot of people at some point. Wouldn't it be nice if the compiler could spot those kind things...? I would have thought such detection is possible. There might be some settings in Visual Studio to do it.

[Arjay]

I generally never makes mistakes like this in my code - I'm not a super programmer, but what I do is follow a certain naming style that helps prevents this sort of thing.

Without getting into a naming religious discussion, here's what works for me...

All field names are pascal case and prepended with an underscore ( '_' ). So listOfItems and someInteger become:


private List<Queue> _listOfItems;
private int _someInteger;


Local variables or method parameters are camelCase and never have an underscore.

So if I make an accidental assignment:

public MyClass()
{
List<Queue> listOfItems = new List<Queue>();
listOfItems.Add(new Queue()); // Okay but using local variable
someInteger = 0; // COMPILER ERROR ( someInteger undefined )
}

And then later....

public void SetValue()
{
someInteger = 1; // COMPILER ERROR (undefined variable)
listOfItems.Add(new Queue()); // COMPILER ERROR (undefined variable)
}


Using an underscore for class fields reduces ambiguity between field variables and local variables

public void SetValue( int someInteger )
{
_someInteger = someInteger;
_listOfItems.Add( new Queue( ) );
}


If we had defined the _someInteger class field without the underscore, we'd need to use 'this.' to clear up the ambiguity.

public void SetValue( int someInteger )
{
someInteger = someInteger; // Ambiguous

this.someInteger = someInteger; // Life is good
}


I don't like using 'this.' because it makes me feel like a programming amateur. The reason being is that, in the context of a class, all member fields are 'this' by definition because they are relative to an instance of the class, so tacking on 'this.' to member fields is redundant. I use an underscore because it immediately shows me that the variable is a class field and is shorter to type than 'this.'.

[memeloo]

Without getting into a naming religious discussion, here's what works for me...
it's too late :p

All field names are pascal case and prepended with an underscore ( '_' ).
:thumbd: I hate it * 10^306 ;) as much as writing datatype prefixes

Using an underscore for class fields reduces ambiguity between field variables and local variables
once again, it's so horrible :cry: I'm glad that the coding standards where I work does not alow this ;)

I don't like using 'this.' because it makes me feel like a programming amateur. The reason being is that, in the context of a class, all member fields are 'this' by definition because they are relative to an instance of the class, so tacking on 'this.' to member fields is redundant. I use an underscore because it immediately shows me that the variable is a class field and is shorter to type than 'this.'.
I love "thises" and I "this" everything and everywhere. they light so pretty in blue (or in any other custom color) in the editor and you instantly know what it is.

[BigEd781]

Well, memeloo, I completely disagree and I code to a standard almost identical to Arjay. However, that's what is great about it; it is subjective, and as long as you maintain consistency it does not matter which specific style you stick to. I can't stand 'this' prepended to everything. It is simply redundant and unnecessary, and it also creates ambiguity between class level variable and method parameters. But again, it doesn't matter; it's your code, and as long as you are consistent the style itself is irrelevant.

[Arjay]

Yep. Some guys prefer to use 'this.' everywhere. Remember, it makes your code look amateurish because it says "I like coding more characters when there's a shorter alternative." If it's a company standard, then it makes your company look amateurish. Food for thought. :wave:

Here's another amateurish thing: Naming variables and classes with a 'my' prefix. Nothing screams "I'm a beginner" like naming a variable 'myCount' or a class 'MyPerson'.

I've held the belief that using something to clearly distinguish a class field from a local variable is a good thing for a long time now and early on settled on an underscore. I was disappointed when Microsoft came out with their initial naming standards years ago that supported using 'this.'. I suspect at the time there was a lot of VB or Java influence. Fortunately they've backpedaled a bit and now recommend using the underscore rather than 'this.'.

I'm glad to see '_' gaining traction so much that code assist tools such as Resharper have now made it part of their standard.

I usually avoid getting into naming convention wars because quite frankly it baffles me as to why some folks code the way they do.

For example, why do some folks never seem to use whitespace?

for(int x=0;x<10;x++)

I find this to be more readable
for(int x = 0; x < 10; x++ )

Here are some possibilities why some folks don't use whitespace:
No whitespace compiles faster.
Saves space in source files.
That readability doesn't matter.
It's faster to code without using whitespace.

Well, one thing we all might be able to agree on is whatever naming convention or standard that you use - use it consistently throughout your program.

[Arjay]

Well, memeloo, I completely disagree and I code to a standard almost identical to Arjay. However, that's what is great about it; it is subjective, and as long as you maintain consistency it does not matter which specific style you stick to. I can't stand 'this' prepended to everything. It is simply redundant and unnecessary, and it also creates ambiguity between class level variable and method parameters. But again, it doesn't matter; it's your code, and as long as you are consistent the style itself is irrelevant.I completely agree. It is Memeloo's code and he certainly should code it the way he prefers.

My other comments are a bit tongue in cheek and I was having a bit of fun. :D I code to a certain style but certainly don't expect others to have to follow.

[memeloo]

I suggest to use the "_" to indicate the level of inheritance, then the use of "base" and "new" would also be redundant:


class _Human
{
protected int _power = 5;
public int _Power { get { return _power; } }
}

class _Superhero : _Human
{
protected int __power = 50;
public int _HumanPower { get { return _power; } }
public int __Power { get { return __power; } }
}

class _Me : _Superhero
{
protected int ___power = 500;
public int __SuperheroPower { get { return __power; } }
public int ___Power { get { return ___power; } }
}


it's beautiful, isn't it? :D

vs.


class Human
{
protected int power = 5;
public int Power { get { return this.power; } }
}

class Superhero : Human
{
protected new int power = 50;
public int HumanPower { get { return base.power; } }
public new int Power { get { return this.power; } }
}

class Me : Superhero
{
protected new int power = 500;
public int SuperheroPower { get { return base.power; } }
public new int Power { get { return this.power; } }
}

[BigEd781]

Ok...that would confuse the hell out of me :)

[Arjay]

I suggest to use the "_" to indicate the level of inheritance, then the use of "base" and "new" would also be redundantIf you like that style and think it provides value, then go with it. :thumb:

[rliq]

I must admit, I'm under no fixed coding standards regime.

I used to code in Visual C++, my member variables were prefixed with "m_". When I moved to Visual C#, initially I still used "m_", but gradually changed to just "_". Why? In both cases I was using Microsoft products and that's what Microsoft do. Don't ask me why, I don't know. All I know is that, doing it the same way the owner of product does it, means you will do it the same way most people end up doing it. And as a result... You will be able to read/absorb examples and other peoples code more easily.

I'm not saying one way is better than the other, but if everybody agrees to drive on the same side of the road, then all we have to worry about is the speed limit.

[nelo]

I generally never makes mistakes like this in my code - I'm not a super programmer, but what I do is follow a certain naming style that helps prevents this sort of thing.
I wouldn't expect you to make this kind of mistake. What I meant is that people just starting out in C# and object oriented programming are likely to make this mistake. Good point on the having a standard/convention. By sticking to that you actually prevent certain type of problems form ever occuring.

On the naming conventions/coding I tend to adjust it based on the company or project I'm working on. I've noticed for example that in the current project the team leader prefers 'String' to 'string' so I've adopted that recently. By the way I'm an '_' for class fields and generally do not use 'this'... :)

[Arjay]

I wouldn't expect you to make this kind of mistake. What I meant is that people just starting out in C# and object oriented programming are likely to make this mistake.I didn't think your comments were directed my way. :wave:

[Mutant_Fruit]

I've noticed for example that in the current project the team leader prefers 'String' to 'string' so I've adopted that recently

Funnily enough, these are actually two different things. Take this example:


namespace Blah {

// This class represents a 'string' from 'String Theory'
public class String
{
public String () {}
}


public void Method ()
{
String s = "fail"; // WHOOPS! This won't compile
string s = "win!" // This does work
}
}


The thing is, 'string' is essentially a typedef to System.String as defined in the core library (mscorlib.dll). It is impossible for anyone to override this and replace it with another class.

'String' means the class with the name 'String' which is available in the current namespace or in one of the namespaces listed in the 'using' statements at the top. As you can see above, this is not guaranteed to be 'System.String' as declared in mscorlib.

The same is true for int/Int32, long/Int64, short/Int16. Each of those keywords is guaranteed to link the corresponding value type as declared in mscorlib, but each of those class names is whatever class is in the current namespace.

It's a small point, but worth noting :)

[nelo]

That's a very good point! As you said small but worth noting. I might revert back to using to the 'string'. Generally speaking I have visibility of the entire code base so I'm unlikely to come across a 'String' other than 'System.String' but still you raise a good point.

[Arjay]

For what it's worth, I use String when I'm using the static members of the class (e.g. String.Format); otherwise I use string.