Compiler Error Request.

[Sean Wolfe]

I have a request for the c# compiler one that is an obvious oversight in
my opinion. I'm not sure if this is already being implemented in
Whidebey, bu i would hope to find it in there, or in the next version.

Working with properties, and the neaming convention that Microsoft has
recommended for developing in C#, it is easy for one to have a circular
reference. This reference could easily be prevented by a Compiler error,
but as of 1.1 frameworks, it does not.

take the following code for example:

public class Foo
{
private int bar;

public int Bar
{
get{ return this.Bar; } // <-- this should be a
// compiler error.
}
}

This problem is further exaserbated by the fact that the VS.NET IDE's
Intellisense often chooses the Public version of a member before a
private as you are typing.

Another situation arises in which you are trying to access a private
member withing a class while using a property or method and end up using
a public Property. This is a problem because when you meant to access
the private member field, you access the Public Property method and
incur a performance penalty. Teh compiler should thorw warnings if it
detects such behavior.

Take this code for example:

public class Foo
{
private int bar;

public int Bar
{
get{ return this.bar; }
}

public int FooBar(int param)
{
// The following line should throw a warning.
return (this.Bar + param);
}
}
These are common mistakes i see happen in a development team using C#.
They are such subtle mistakes. Ones that a Compiler could pick up
easily. While i really enjoy proramming in this language, and developing
with it. i fear that this is one of the kinds of issues that come up
that makes C# often criticized for not being a language that is useable
in large development projects and teams.

I often feel this is not true, because I feel with some best practices
C# can be a great productivity enhancer. That is from experience in
developing large applicaitions in a team. But these subtle littpe
problems point to otherwise. Please fix this.

Sean

[Marina]

On request 1, I agree, it would be nice if the compiler could determine
recursive calls like this. On the other hand, you will find this error
immediately the first time you access this property and you get a
stackoverflowex ception.

As for #2, I disagree. Often you do want to use the property and not the
underlying variable. Perhaps you are doing something in the property that
is more then just retreiving a private member, and your function code would
want to use the property to have that code execute. But then there are
times when you want the raw variable data.

There is no way for the compiler to tell which situation it is, and it is
your job as the developer to make sure you are accessing the correct one.
You can make this easier, by not differing the property and the private
member by case only - but actually make them more different then that, so
you are always consciously picking the correct one.

You can't have the compiler do everything for you. It's not unreasonable to
expect people to be aware of these things - and this is no way reflects on
how useful the language is. If these small issues make the language
unusable for your team for large projects, then I think there is a bigger
problem at hand.

But in either case, after you make this mistake once or twice, you will just
become aware of it, and you won't need the compiler to catch it.

"Sean Wolfe" <no*****@please .com> wrote in message
news:eF******** ******@TK2MSFTN GP09.phx.gbl...

I have a request for the c# compiler one that is an obvious oversight in
my opinion. I'm not sure if this is already being implemented in
Whidebey, bu i would hope to find it in there, or in the next version.

Working with properties, and the neaming convention that Microsoft has
recommended for developing in C#, it is easy for one to have a circular
reference. This reference could easily be prevented by a Compiler error,
but as of 1.1 frameworks, it does not.

take the following code for example:

public class Foo
{
private int bar;

public int Bar
{
get{ return this.Bar; } // <-- this should be a
// compiler error.
}
}

This problem is further exaserbated by the fact that the VS.NET IDE's
Intellisense often chooses the Public version of a member before a
private as you are typing.

Another situation arises in which you are trying to access a private
member withing a class while using a property or method and end up using
a public Property. This is a problem because when you meant to access
the private member field, you access the Public Property method and
incur a performance penalty. Teh compiler should thorw warnings if it
detects such behavior.

Take this code for example:

public class Foo
{
private int bar;

public int Bar
{
get{ return this.bar; }
}

public int FooBar(int param)
{
// The following line should throw a warning.
return (this.Bar + param);
}
}
These are common mistakes i see happen in a development team using C#.
They are such subtle mistakes. Ones that a Compiler could pick up
easily. While i really enjoy proramming in this language, and developing
with it. i fear that this is one of the kinds of issues that come up
that makes C# often criticized for not being a language that is useable
in large development projects and teams.

I often feel this is not true, because I feel with some best practices
C# can be a great productivity enhancer. That is from experience in
developing large applicaitions in a team. But these subtle littpe
problems point to otherwise. Please fix this.

Sean

[C# Learner]

Sean Wolfe <no*****@please .com> wrote:

I agree with your first suggestion but not with your second...

Take this code for example:

public class Foo
{
private int bar;

public int Bar
{
get{ return this.bar; }
}

public int FooBar(int param)
{
// The following line should throw a warning.
return (this.Bar + param);
}
}

What if Bar was implemented like this:

public int Bar
{
get { return someFlagIsSet ? bar : 0; }
}

[Sean Wolfe]

C# Learner wrote:

Sean Wolfe <no*****@please .com> wrote:

I agree with your first suggestion but not with your second...

Take this code for example:

public class Foo
{
private int bar;

public int Bar
{
get{ return this.bar; }
}

public int FooBar(int param)
{
// The following line should throw a warning.
return (this.Bar + param);
}
}

What if Bar was implemented like this:

public int Bar
{
get { return someFlagIsSet ? bar : 0; }
}

I guess I do agree with you guys on the Second issue that this can
clearly be a best practices issue. But the first one is just an
oversight by the compiler. Whether or not it gets caught the first time
that it's run, or get a stack overflow, the call clearly shouldn't
compile. Compilers these days are smart enough to know such things.
Also having Intellisense choosing the Public item first doesn't help.

Sean

[Jeffrey Tan[MSFT]]

Hi Sean,

Thank you for posting in the community! My name is Jeffrey, and I will be
assisting you on this issue.

Based on my understanding, you have tabled 2 proposals for C# compiler
error checking.
=============== =============== =============== ==
For your #2, I agree with what Marina said, the compiler gives you the
flexibility to use Property validation, etc, so I think it is by the design
goal.

For your #1, I think C# is a case-sensitive language, and the case type
error is a use error in your code, so I think you should be careful of this
issue in your programming work.

But I also know your concern, you feel that C# compiler should be more
convinient for the developers and reduce more fallible possibility. I think
your concern also makes sense, so I suggest you provide your suggestion and
concern to Microsoft at:
http://register.microsoft.com/mswish/suggestion.asp
you also can email to: ms****@microsof t.com

=============== =============== =============== =
Thank you for your patience and cooperation. If you have any further
concerns, please feel free to post it in the group. I am standing by to be
of assistance.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

[Jeffrey Tan[MSFT]]

Hi Sean,

Does my reply makes sense to you?
Do you still have concern? Please feel free to feedback to me, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.