csharp concepts 101

[HolyCow]

I'm in the early stages of learning csharp. I have an example class, and
I'm trying to understand it clearly. I've included comments and questions.
Any clarification would be greatly appreciated.

class Point
{
// This is a constructor because it is named the
// same as the class? I'm also defining 2 parameters that
// can be passed to an instance of this class.
public Point(int x, int y)
{
this.x = x; //setting the value of the member fields
this.y = y; //to the values passed.
}

// Declaring member fields.
// Why do we declare them after they have
// been referenced in the constructor?
// Declaring member fields with the same name as the parameters
// seems odd -- seems like a bad idea?
public int x;
public int y;
}

[Jon Skeet [C# MVP]]

HolyCow <no****@nowhere.com> wrote:

I'm in the early stages of learning csharp. I have an example class, and
I'm trying to understand it clearly. I've included comments and questions.
Any clarification would be greatly appreciated.

class Point
{
// This is a constructor because it is named the
// same as the class?
Yes.
I'm also defining 2 parameters that
// can be passed to an instance of this class.
The parameters are passed to the constructor - you don't pass
parameters to an instance as such.
public Point(int x, int y)
{
this.x = x; //setting the value of the member fields
this.y = y; //to the values passed.
}

// Declaring member fields.
// Why do we declare them after they have
// been referenced in the constructor?
The textual location doesn't matter (in this context - there are a
*very* few places where the order matters).
// Declaring member fields with the same name as the parameters
// seems odd -- seems like a bad idea?
Some people think it is, some think it isn't. I use the convention
shown here, but others prefer to use _x or m_x.
public int x;
public int y;
}

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Bob Grommes]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

HolyCow <no****@nowhere.com> wrote:

// Declaring member fields with the same name as the parameters
// seems odd -- seems like a bad idea?

Some people think it is, some think it isn't. I use the convention
shown here, but others prefer to use _x or m_x.

Or, use the convention of prefixing all references to class members with
"this."

--Bob

[Jeff Louie]

HolyCow...The problem is that useful names are in short supply, so most
of
us want to reuse the same name for member fields and local fields. If
you
don't have a standardized method of differentiating between member
fields
and local fields you can get yourself into lots of hot water. The
standard C#
approach is to preface member fields with this within a method with a
potential name collision with a local field. The standard C++ approach
is to
simply prepend m_ to the member field name. Another approach would be to
prepend in to a parameter name such as inSomeString. so

this.x= x
m_x= x
SomeString= inSomeString

Regards,
Jeff
// Declaring member fields with the same name as the parameters
// seems odd -- seems like a bad idea?
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Jon Skeet [C# MVP]]

Jeff Louie <je********@yahoo.com> wrote:

HolyCow...The problem is that useful names are in short supply, so
most of us want to reuse the same name for member fields and local
fields. If you don't have a standardized method of differentiating
between member fields and local fields you can get yourself into lots
of hot water.
So people keep saying, but I can't remember the last time it ever bit
me, whereas I *do* find prefixes lower the readability for me. If you
keep your methods short enough (which is good for other reasons), it
should be obvious which is which.
The standard C# approach is to preface member fields with this within
a method with a potential name collision with a local field.

No, there *is* no standard C# approach. That's *a* common approach, but
it's not standard by any means.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jeff Louie]

Jon... I am speaking from my personal experience. Once burned, a bit
more
careful. I do agree that the prefixes are bothersome, but I would
recommend
using m_x in a non trivial C++ project despite the lowered readabililty.

Regards,
Jeff

So people keep saying, but I can't remember the last time it ever bit

me, whereas I *do* find prefixes lower the readability for me. If you
keep your methods short enough (which is good for other reasons), it
should be obvious which is which.<
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Jon Skeet [C# MVP]]

Jeff Louie <je********@yahoo.com> wrote:

Jon... I am speaking from my personal experience. Once burned, a bit
more careful. I do agree that the prefixes are bothersome, but I
would recommend using m_x in a non trivial C++ project despite the
lowered readabililty.

In C++ it's a fairly standard convention, and I'd probably use it
there. It's less standard in C#, and having never had a problem, I'd
rather have higher readability. Each to their own though :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too