Properties and Linq: beware this trap

[RayLopez99]

For some reason, I spent a good part of an hour before I caught this
mistake. And I thought I knew everything there is to know about C#,
sorry Arne.

Truth is, I've used the second "incorrect" version of properties, I
swear, and did not have a problem before, but with Linq you get a
runtime error System.StackOverflowException (it compiles fine
however).

Anyway, problem solved.

RL

Properties when used with Linq queries should obey this format.

CORRECT:
private int productXYZ;
public int ProductXYZ
{
get { return productXYZ; }
set { productXYZ = value; }
}

INCORRECT:

private int productXYZ;
public int ProductXYZ
{
get { return productXYZ; }
set { ProductXYZ = value; } //error
}

INCORRECT:

private int productXYZ;
public int ProductXYZ
{
get { return ProductXYZ; } //error
set { productXYZ = value; }
}

http://stackoverflow.com/questions/1437791/overloading-getter-and-setter-causes-stackoverflow-in-c

http://stackoverflow.com/questions/...e-always-throws-system-stackoverflowexception

 

[Arne Vajhøj]

For some reason, I spent a good part of an hour before I caught this
mistake. And I thought I knew everything there is to know about C#,
sorry Arne.

Truth is, I've used the second "incorrect" version of properties, I
swear, and did not have a problem before, but with Linq you get a
runtime error System.StackOverflowException (it compiles fine
however).

Properties when used with Linq queries should obey this format.

CORRECT:
private int productXYZ;
public int ProductXYZ
{
get { return productXYZ; }
set { productXYZ = value; }
}

INCORRECT:

private int productXYZ;
public int ProductXYZ
{
get { return productXYZ; }
set { ProductXYZ = value; } //error
}

INCORRECT:

private int productXYZ;
public int ProductXYZ
{
get { return ProductXYZ; } //error
set { productXYZ = value; }
}

I don't think this is specific for LINQ.

Any usage of the incorrect properties should create
an infinite recursion.

Arne

 

[Felix Palmen]

I don't think this is specific for LINQ.

Any usage of the incorrect properties should create
an infinite recursion.

Second. And by the way, there's a reason why naming private members with
a leading underscore (here: _productXYZ) is considered good practice:
- It's much easier to spot errors like this
- There are CLR languages with case-insensitive identifiers.

If you don't have any code in your getters and setters, just leave out
the explicit definition of the private member and rely on the automatic
get and set code.

Regards,
Felix

 

[andy]

I don't think this is specific for LINQ.

Any usage of the incorrect properties should create
an infinite recursion.

Second. And by the way, there's a reason why naming private members with
a leading underscore (here: _productXYZ) is considered good practice:
- It's much easier to spot errors like this
- There are CLR languages with case-insensitive identifiers.

If you don't have any code in your getters and setters, just leave out
the explicit definition of the private member and rely on the automatic
get and set code.

Regards,
Felix

--
 Felix Palmen       (Zirias)  + [PGP] Felix Palmen <[email protected]>
 web:  http://palmen-it.de/ |            http://palmen-it.de/pub.txt
 my open source projects:     |   Fingerprint: ED9B 62D0 BE39 32F9 2488
 http://palmen-it.de/?pg=pro +                5D0C 8177 9D80 5ECF F683

I'm with Felix on the underscore thing.
Some places I work aren't though.

propfull tab
Gives you the template thingummy for a property with backing variable
in VS2010.

 

[Jeff Johnson]

I'm with Felix on the underscore thing.

I'm with MICROSOFT on the underscore thing. Call me a sheep if you want, but
I embraced their new naming standards for .NET and I'm pretty happy with
them. My old Hungarian VB code is almost painful to my eyes now. I still
think camel casing is ugly as hell, but I've learned to blank it out.

 

[kndg]

I'm with MICROSOFT on the underscore thing. Call me a sheep if you want, but
I embraced their new naming standards for .NET and I'm pretty happy with
them. My old Hungarian VB code is almost painful to my eyes now. I still
think camel casing is ugly as hell, but I've learned to blank it out.

As far as I know, the naming for private member is not covered in the
Microsoft naming guidelines. I have seen codes from Microsoft that use a
variety of naming style such _xxx, xxx or even m_xxx. I think it is just
a matter of personal preference but the generally accepted rule is, it
should be consistent throughout the source code. I myself personnally
prefer the camel casing and don't like the underscore things especially
when involves operators (such as --xxx vs --_xxx where I find the former
would read better). I also keeps my method body as short as possible so
that I have no trouble to differentiate my private member with my local
variable. However, whether it is hungarian or a camel casing or any
other style, if coupled with property, all these things becomes void as
you will access the variable through a property anyway (which should
have pascal casing).

 

[Felix Palmen]

As far as I know, the naming for private member is not covered in the
Microsoft naming guidelines.

Indeed, the only thing Microsoft's naming guidelines have to say about
instance members is:

"You should not define public or protected instance fields."

There seem to be rules for publicly visible names only. But,
interestingly, when you use the automatic properties of VB, the private
member is named with a prefixed underscore.

The practice of naming private members with a leading underscore is used
a lot and I assume it is part of a lot of naming guidelines out there
(at least, it is part of perl's naming guidelines*)

Regards,
Felix

* and it is quite important there because perl lacks language support
for private members, therefore they have to be private "by convention"

 

[RayLopez99]

The practice of naming private members with a leading underscore is used
a lot and I assume it is part of a lot of naming guidelines out there
(at least, it is part of perl's naming guidelines*)

I think *leading* underscores is bad practice in C/C#, since that is
conventionally reserved for system variables in the library. What
Jeff Johnson is referring to (I think) is *trailing* underscores,
which MSFTs style guide says should be used for local temporary
variable such as in a loop.

RL