Naming conventions regularly followed?

[Cristof Falk]

I wanted to get a feel. The documentation gives naming conventions for
public/protected members. Is this truly widely adopted?

And what about using the same conventions for private members and
variables?

My coding preference is to use this everywhere (banish Hungarian and
follow the capitalization rules) but I need to sell it to team
members.

Thanks!

[Jon Skeet [C# MVP]]

Cristof Falk <cf**@critterdesign.net> wrote:

I wanted to get a feel. The documentation gives naming conventions for
public/protected members. Is this truly widely adopted?
Pretty widely, yes.
And what about using the same conventions for private members and
variables?
I personally do, yes - but it's less widely followed than the
public/protected one is.
My coding preference is to use this everywhere (banish Hungarian and
follow the capitalization rules) but I need to sell it to team
members.

I certainly haven't seen any particularly good reasons *not* to, and I
find code without prefixes etc much more readable. The only thing you
need to beware of (IME) is making sure that your properties access the
variable, rather than recursing, eg:
// Careful of this
int foo;
public int Foo
{
get { return Foo; }
set { Foo = value; }
}

// ... you want this instead
int foo;
public int Foo
{
get { return foo; }
set { foo = value; }
}

However, it's very easy to find such problems, and I can only remember
doing it once myself.

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

[Jon Skeet [C# MVP]]

Cristof Falk <cf**@critterdesign.net> wrote:

I wanted to get a feel. The documentation gives naming conventions for
public/protected members. Is this truly widely adopted?
Pretty widely, yes.
And what about using the same conventions for private members and
variables?
I personally do, yes - but it's less widely followed than the
public/protected one is.
My coding preference is to use this everywhere (banish Hungarian and
follow the capitalization rules) but I need to sell it to team
members.

I certainly haven't seen any particularly good reasons *not* to, and I
find code without prefixes etc much more readable. The only thing you
need to beware of (IME) is making sure that your properties access the
variable, rather than recursing, eg:
// Careful of this
int foo;
public int Foo
{
get { return Foo; }
set { Foo = value; }
}

// ... you want this instead
int foo;
public int Foo
{
get { return foo; }
set { foo = value; }
}

However, it's very easy to find such problems, and I can only remember
doing it once myself.

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

[cody]

> I wanted to get a feel. The documentation gives naming conventions for

public/protected members. Is this truly widely adopted?

And what about using the same conventions for private members and
variables?

private variables should always start with a lowercase letter (some people
are swearing on a leading underscore to distinguish between variable and
property).
but naming conventions for private stuff is not so important since it is not
part of your api,
and naming changes in private members does not affect client code.
anyway, one should always follow naming conventions, public or private.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

[cody]

> I wanted to get a feel. The documentation gives naming conventions for

public/protected members. Is this truly widely adopted?

And what about using the same conventions for private members and
variables?

private variables should always start with a lowercase letter (some people
are swearing on a leading underscore to distinguish between variable and
property).
but naming conventions for private stuff is not so important since it is not
part of your api,
and naming changes in private members does not affect client code.
anyway, one should always follow naming conventions, public or private.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk