Why does the compiler let this happen

[Guest]

Why doesn't the compiler throw an error on a block of code like this:

public string Email
{
get
{
return Email;
}
}


I can't think of any time where recursion would be useful in a property
getter and it is something that I have accidently typed more than once.

 

[Marina]

I guess it doesn't rule out the fact that you *could* have some sort of
weird code where you are setting some variable and then wish to recursively
call the property. A property get, is really just a method wrapper, after
all, so it is conceivable.

Now, in practical terms, no one should really need a recursive property,
since typically it just retrieves a value stored privately. However, the
compiler doesn't make any assumptions.

 

[Anders Norås [MCAD]]

public string Email

{
get
{
return Email;
}
}


I can't think of any time where recursion would be useful in a property
getter and it is something that I have accidently typed more than once.

The compiler allows this because it is perfectly legal for a property getter
to return itself. You're right that recursion is seldom used in a getter,
but imagine how irretating it would be if the compiler didn't allow this
when you needed this possibility.

Anders Norås
http://dotnetjunkies.com/weblog/anoras/

 

[Guest]

Wouldn't and weird code be better handled in a loop since gets and sets are
not parameterized?

 

[Guest]

When do you need this? I can't think of any _good_ examples. Everything I
can think would be better done in a loop.

 

[Marina]

I'm not saying that this scenario is better. But it is possible, that is
all - and there is potentially a scenario where it is necessary. In any
case, it is not the compiler's job is not to dictate programming style.

 

[Alan Pretre]

Why doesn't the compiler throw an error on a block of code like this:

public string Email
{
get
{
return Email;
}
}

You might consider prefixing your member variables with an underscore, then
inadvertent recursion like this wouldn't happen. Such as

public string Email
{
get
{
return _Email;
}
}

This is a common convention.

-- Alan

 

[Guest]

The same reason it won't give an error if you write
if(some_bool = true) ...
Because it's syntactically valid. Compiler errors are a matter of syntax,
not style. However, it would make sense to me if your code produced a
compiler *warning* because 99 times out of 100 it's a runtime problem just
waiting to happen.

As an interesting aside,
if(some_bool = true)
produces a helpful warning, but
if((some_bool = true) || (some_bool = true))
doesn't

 

[Peter N Roth]

In the sense that using the leading underscore is a
common practice, the word 'common' is understood
to have the meaning "5 a : falling below ordinary
standards : SECOND-RATE b : lacking refinement : COARSE"
(cf Merriam Webster).

Better is to use the recommended practices of camel and
Pascal casing.
--
Grace + Peace,
Peter N Roth
Engineering Objects International
http://engineeringobjects.com
Home of Matrix.NET

 

[J.Marsch]

While I agree with you that this is something that you would probably never
do (at least I can't think of a reason why you would), I do have to say that
I don't really go for getting an error from the compiler when you do
something like this. It's not syntactically illegal. And, while this
recursion might be something that you wouldn't ever do, what about the next
code construct that "no one would ever do".

You see, you open up that precedent (compiler erroring on "no one would ever
do this on purpose"), and sooner or later, someone will need to do that.
Perhaps this would be good compiler warning instead.

 

[Scott Jacobsen]

In the sense that using the leading underscore is a
common practice, the word 'common' is understood
to have the meaning "5 a : falling below ordinary
standards : SECOND-RATE b : lacking refinement : COARSE"
(cf Merriam Webster).

Better is to use the recommended practices of camel and
Pascal casing.

Bah. You had to dig way down to the fifth meaning of common. Industry
recommended practices is always a sad amalgamation of design by committee.
In this century, when every editor has code completion, _name is the way to
go. Just type _<ctrl-spc> and you get a list of all your private members.
Type a<ctrl-space> and you get every symbol starting with a, no matter
where it is. _<ctrl_spc> shows you all the private members, without even
having to read the code. Clearly this facilitates lazyness, and lazyness is
the most important programming virtue. Something industry committees just
can't grok.

 

[Jon Skeet [C# MVP]]

Bah. You had to dig way down to the fifth meaning of common. Industry
recommended practices is always a sad amalgamation of design by committee.
In this century, when every editor has code completion, _name is the way to
go. Just type _<ctrl-spc> and you get a list of all your private members.
Type a<ctrl-space> and you get every symbol starting with a, no matter
where it is. _<ctrl_spc> shows you all the private members, without even
having to read the code. Clearly this facilitates lazyness, and lazyness is
the most important programming virtue. Something industry committees just
can't grok.

Using any other convention, of course, you can just use "this." to get
the list of members.

Personally I find the underscore convention a hindrance in terms of
readability - I have a mental hiccough every time I see it in a line of
code, so it slows me down

 

[ramon.leon]

Using any other convention, of course, you can just use "this." to get
the list of members.

Personally I find the underscore convention a hindrance in terms of
readability - I have a mental hiccough every time I see it in a line of
code, so it slows me down

Underscores are nasty, any code that can't be read outloud and
discussed verbally needs fixing. The best two conventions I've seen
that lead to nice readable code, is to prefix members with "its" or
"the", you get the same benifit as _, different names than local
variables to avoid accidental assignment, removes the need for "this."
which is also ugly, and it actually sounds nice when spoken and read.
Code is for "humans", not computers, you should use standard human
language conventions as much as possible. It also makes it much easier
to communicate with the customer, because you can talk code, and it'll
make sense to them, and they will talk back in that same lingo, often
giving you further insight into your own code.

 

[Peter N Roth]

I have no idea how etymologists rank definitions...

Laziness is a virtue akin to necessity. Applause for that.
Still, those _s at the left of a word stick in my eye like
little needles.

Perhaps I am making my classes small enough that
I dont need Intellisense to make a list?
--
Grace + Peace,
Peter N Roth
Engineering Objects International
http://engineeringobjects.com
Home of Matrix.NET

 

[J.Marsch]

Your point about "code should sound nice when spoken" definitely strikes a
chord. Having member names that make sense when you discuss them led us
away from the ProperCase/pascalCase pattern that MS suggested for Properties
and their corresponding private field variable names. We ended up going to
the underscore, (still a little weird in a verbal conversation "in this
case, assign the value to the 'underscore'<propertyName> member because we
don't want the 'get' behavior" etc... Mind you, we only use the "_" for
fields that are storage for a property.

In the Delphi days, we used to prefix the private members that stood behind
a Property with a capital "F":
MyProperty and FMyProperty. (don't ask where that comes from, I think the
"F" was supposed to stand for "field").

We did end up using "this." in our code. For about the first month, it
looked really ugly to me. But now it is completely natural (Stockholm
Syndrome???) and it is very clear when we are reading code that references
an instance member vs. a local member.

 

[Scott Jacobsen]

I have no idea how etymologists rank definitions...

Laziness is a virtue akin to necessity. Applause for that.
Still, those _s at the left of a word stick in my eye like
little needles.

Perhaps I am making my classes small enough that
I dont need Intellisense to make a list?

You're right that the real solution is a small well defined class. Then it
is easy to understand no matter what convention is used. Which is what I
always tell people when they start talking about "coding standards". I'm
not sure why I got all fired up on that one.

Coming from a java/c++ background, I am somewhat vexed by how to name my
member variables in .net because of properties. You have to mess up the
name with something since the property will have the name you want to use
for the member variable. I tried the prefix 'the' for a while, but I
thought that was horrible. "my" is just as bad. Having one start with a
capital and the other a lower case letter is just asking for trouble. I'm
going for "m_" now.

 

[Jon Skeet [C# MVP]]

Having one start with a capital and the other a lower case letter is
just asking for trouble.

So people say, but that's what I use, and I've never had a problem with
it.

Oh for properties being able to declare member variables which only
they could access though... that would improve things a lot, IMO.

 

[Richard Blewett [DevelopMentor]]

So people say, but that's what I use, and I've never had a problem with
it.

I use it too and don't have problems with it either.

Oh for properties being able to declare member variables which only
they could access though... that would improve things a lot, IMO.

Hmm, I can see this work for places where you want to perform validation on
the set and for decoupling the type of the property from the underlying
state but it falls apart for providing readonly properties (no-one can
update the value). I guess as another tool in the toolbox it would work.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

 

[Scott Jacobsen]

So people say, but that's what I use, and I've never had a problem with
it.

In a case sensitive language varying symbol names only be case, foo and Foo
is a really bad idea. It is programming 101. (Does MS really recommend
this?) The human eye sees what it wants when reading text, not what is
there. How often have you written "the the" when you mean "the", and proof
read your document 10 times and not seen it? The same goes for letter case
in code.

Perhaps you are very careful all the time, and always use the variable when
you mean the variable, and the property when you mean the property. And
perhaps every author of every library you depend on is equally careful. Of
course no body can be that careful all the time. 99.9% of the time your
code will work the same way if you do mix it up, so there really is no way
to know if you do mix it up now. Little time bombs are being set in C# code
being written all over the world right now.

For example, you write this class:
class Foo {
private Data myData;

public Data MyData {
get { return myData; }
set { myData = value; }
}

public Bar() {
// oops. Should be using the property
// here. But every thing works right
// now, so no tests catch it....
doSomething(myData);
}
}


A year later you modify the MyData property:
public Data MyData {
get {
// This line was added as something important
// needs to be done.
doSomethingImportantBeforeReturning()
return myData;
}
set { myData = value; }
}

public Bar() {
// Uh-oh. I never noticed this was a direct
// access, and not a property call, and now
// my code fails every 13.5 hours only when
// I'm on vacation!
doSomething(myData);
}

Oh for properties being able to declare member variables which only
they could access though... that would improve things a lot, IMO.

This sounds like a real solution. I predict, once enough of these little
time bombs go off, MS will do something like this. Or not. It is Microsoft
after all...

 

[Jon Skeet [C# MVP]]

In a case sensitive language varying symbol names only be case, foo and Foo
is a really bad idea. It is programming 101. (Does MS really recommend
this?) The human eye sees what it wants when reading text, not what is
there. How often have you written "the the" when you mean "the", and proof
read your document 10 times and not seen it? The same goes for letter case
in code.

Then why hasn't it been a problem for me? I'm far from superhuman. Case
is pretty distinctive to me.

Perhaps you are very careful all the time, and always use the variable when
you mean the variable, and the property when you mean the property. And
perhaps every author of every library you depend on is equally careful. Of
course no body can be that careful all the time. 99.9% of the time your
code will work the same way if you do mix it up, so there really is no way
to know if you do mix it up now. Little time bombs are being set in C# code
being written all over the world right now.

For example, you write this class:
class Foo {
private Data myData;

public Data MyData {
get { return myData; }
set { myData = value; }
}

public Bar() {
// oops. Should be using the property
// here. But every thing works right
// now, so no tests catch it....
doSomething(myData);
}
}

And that's why it would be good to be able to allow a variable to be
local to the property declaration - it would be just as easy to write
_myData in that method.

This sounds like a real solution. I predict, once enough of these little
time bombs go off, MS will do something like this. Or not. It is Microsoft
after all...

Well, I've submitted it as a feature request before now. We'll see...