Class member addressing

[MM]

Hi,

I was taught to use this type of class/member construction (some years
ago I might add) -

class someclass
{
private datatype data1;
private datatype data2;

public someclass( datatype data1, datatype data2 etc)
{
this.data1 = data1;
this.data2 = data2;
etc...

but alot of modern texts seem to decry the use of 'this' to
prefix/access class memebers and don't even seem to bother with explicit
'private'. What's the 'norm' these days? Thanks!

[Michael C]

"MM" <mm@newsgroups. com> wrote in message
news:OF******** ******@TK2MSFTN GP12.phx.gbl...

Hi,

I was taught to use this type of class/member construction (some years ago
I might add) -

class someclass
{
private datatype data1;
private datatype data2;

public someclass( datatype data1, datatype data2 etc)
{
this.data1 = data1;
this.data2 = data2;
etc...

but alot of modern texts seem to decry the use of 'this' to prefix/access
class memebers and don't even seem to bother with explicit 'private'.
What's the 'norm' these days? Thanks!

I find this clearer:

private datatype _data1;
private datatype _data2;

Michael

[Mark R. Dawson]

Hi MM,
I prefer, like Michael C, to put an underscore next to private member
variables to aid readability. I also personally like adding "this" inforont
of variables but it is just personal preference I think it makes code more
clear, others may disagree. I think that when coding it is better to be
explicit, such as declaring variables private as this also aids readability.

Microsoft has some coding guidlelines for writing class libararies, which is
worth reading. Check out
http://msdn.microsoft.com/library/de...guidelines.asp

Hope that helps
Mark R Dawson

"MM" wrote:

Hi,

I was taught to use this type of class/member construction (some years
ago I might add) -

class someclass
{
private datatype data1;
private datatype data2;

public someclass( datatype data1, datatype data2 etc)
{
this.data1 = data1;
this.data2 = data2;
etc...

but alot of modern texts seem to decry the use of 'this' to
prefix/access class memebers and don't even seem to bother with explicit
'private'. What's the 'norm' these days? Thanks!

[Jon Skeet [C# MVP]]

MM <mm@newsgroups. com> wrote:

Hi,

I was taught to use this type of class/member construction (some years
ago I might add) -

class someclass
{
private datatype data1;
private datatype data2;

public someclass( datatype data1, datatype data2 etc)
{
this.data1 = data1;
this.data2 = data2;
etc...

but alot of modern texts seem to decry the use of 'this' to
prefix/access class memebers
It's a personal choice. At work I use "m_variableName " due to the
coding standards there, but at home I write code like the above. So
long as the variables stay private, it makes no odds.
and don't even seem to bother with explicit
'private'. What's the 'norm' these days? Thanks!

Whether you explicitly state "private" or not is even more of a
personal choice - it doesn't make *any* difference to the generated
code. Personally I don't bother with it - because the defaults in C#
are so well chosen (always the most restrictive access available) I
prefer to have it highlighted to me that I've made something *less*
restrictive.

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

[Javaman59]

Hi, MM

Some of this can be addressed straight from Microsofts .Net guidelines...

http://msdn.microsoft.com/library/de...Guidelines.asp

I notice that some books, and web articles, use conventions which contradict
the Microsoft guidelines. I don't know when the guidelines were first
published, but I think that it would make life easier for the whole C#
community if people were to always use them in new code, if they have a
choice to do so.

On to your questions...

class someclass
{
private datatype data1;
You should definitely use Pascal case for class names. This is almost
universal. ie. "class SomeClass". Similarly for any user defined types, ie
"DataType"

I personally have a bit of sypathy for the _ prefix to class members, and
some good authors use it, however the conventions say no, and most C# coders
now avoid it.

"Do not use Hungarian notation for field names. Good names describe
semantics, not type.

Do not apply a prefix to field names or static field names. Specifically, do
not apply a prefix to a field name to distinguish between static and
nonstatic fields. For example, applying a g_ or s_ prefix is incorrect. "
public someclass( datatype data1, datatype data2 etc)
{
this.data1 = data1;
this.data2 = data2;
That's exactly how most C# code does it (except for the upper-low case
anomolies I've pointed out).
but alot of modern texts seem to decry the use of 'this' to
prefix/access class memebers
They are quite correct. One rarely sees "this" in good code, except when it
is needed to disambiguate identitiers (as in the constructor above).
and don't even seem to bother with explicit 'private'.
What's the 'norm' these days? Thanks!

Again, I agree with this, and I agree with Jon's argument for it.

Regards,

Javaman

[Bob Powell [MVP]]

I sort of disagree with the take in "this". this is implicit for members so
one need not type it *except* when using an IDE with intellisense where
typeing "this.som" is way easier than typeing
"SomeLongMethod NameThatsEasyTo Misspell". Having this. in a statement is not
hard to read and adds no overhead for the compiler.

Even though it's discouraged by the style-police I wholeheartedly agree with
the prefix of an underbar in private members because a program written in C#
that doesn't make use of the underbar for private members and relies only on
capitalization for the distinction between the member and the accessor
property is a complete pig to translate to VB.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Ramuseco Limited .NET consulting
http://www.ramuseco.com

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

"Javaman59" <Ja*******@disc ussions.microso ft.com> wrote in message
news:FB******** *************** ***********@mic rosoft.com...

Hi, MM

Some of this can be addressed straight from Microsofts .Net guidelines...

http://msdn.microsoft.com/library/de...Guidelines.asp

I notice that some books, and web articles, use conventions which
contradict
the Microsoft guidelines. I don't know when the guidelines were first
published, but I think that it would make life easier for the whole C#
community if people were to always use them in new code, if they have a
choice to do so.

On to your questions...

class someclass
{
private datatype data1;

You should definitely use Pascal case for class names. This is almost
universal. ie. "class SomeClass". Similarly for any user defined types, ie
"DataType"

I personally have a bit of sypathy for the _ prefix to class members, and
some good authors use it, however the conventions say no, and most C#
coders
now avoid it.

"Do not use Hungarian notation for field names. Good names describe
semantics, not type.

Do not apply a prefix to field names or static field names. Specifically,
do
not apply a prefix to a field name to distinguish between static and
nonstatic fields. For example, applying a g_ or s_ prefix is incorrect. "

public someclass( datatype data1, datatype data2 etc)
{
this.data1 = data1;
this.data2 = data2;

That's exactly how most C# code does it (except for the upper-low case
anomolies I've pointed out).

but alot of modern texts seem to decry the use of 'this' to
prefix/access class memebers

They are quite correct. One rarely sees "this" in good code, except when
it
is needed to disambiguate identitiers (as in the constructor above).

and don't even seem to bother with explicit 'private'.
What's the 'norm' these days? Thanks!

Again, I agree with this, and I agree with Jon's argument for it.

Regards,

Javaman

[Michael C]

"Bob Powell [MVP]" <bob@_spamkille r_bobpowell.net > wrote in message
news:u4******** ******@TK2MSFTN GP12.phx.gbl...

I sort of disagree with the take in "this". this is implicit for members so
one need not type it *except* when using an IDE with intellisense where
typeing "this.som" is way easier than typeing
"SomeLongMetho dNameThatsEasyT oMisspell". Having this. in a statement is not
hard to read and adds no overhead for the compiler.
Try

som ctrl space

I must say I'm suprised at the number of developers who don't know this
extremely useful shortcut :-) I must use it, without exaggeration, 200 times
a day when coding.
Even though it's discouraged by the style-police I wholeheartedly agree
with the prefix of an underbar in private members because a program
written in C# that doesn't make use of the underbar for private members
and relies only on capitalization for the distinction between the member
and the accessor property is a complete pig to translate to VB.

Plus it eliminates conflicts (and hence possible bugs) between variable
name. When naming a private variable or function parameter there is zero
chance it will conflict with a class variable. I believe the MS standard
used to have the underscore and at least some of the private variables in
the framework have it.

Michael

[Michael C]

"Bob Powell [MVP]" <bob@_spamkille r_bobpowell.net > wrote in message
news:u4******** ******@TK2MSFTN GP12.phx.gbl...

I sort of disagree with the take in "this". this is implicit for members so
one need not type it *except* when using an IDE with intellisense where
typeing "this.som" is way easier than typeing
"SomeLongMetho dNameThatsEasyT oMisspell". Having this. in a statement is not
hard to read and adds no overhead for the compiler.
Try

som ctrl space

I must say I'm suprised at the number of developers who don't know this
extremely useful shortcut :-) I must use it, without exaggeration, 200 times
a day when coding.
Even though it's discouraged by the style-police I wholeheartedly agree
with the prefix of an underbar in private members because a program
written in C# that doesn't make use of the underbar for private members
and relies only on capitalization for the distinction between the member
and the accessor property is a complete pig to translate to VB.

Plus it eliminates conflicts (and hence possible bugs) between variable
name. When naming a private variable or function parameter there is zero
chance it will conflict with a class variable. I believe the MS standard
used to have the underscore and at least some of the private variables in
the framework have it.

Michael

[MM]

Thanks to all you guys for the advice - think I'll run with _var and
drop 'this' (atleast outside of the constructor). Still undecided about
the access modifier but will probably keep as I'm abit pendantic. Thanks
to Michael C for pointing out the intellisense hotkey thing - one of the
prime reasons I've kept with 'this'. Cheers, m.

[MM]

Thanks to all you guys for the advice - think I'll run with _var and
drop 'this' (atleast outside of the constructor). Still undecided about
the access modifier but will probably keep as I'm abit pendantic. Thanks
to Michael C for pointing out the intellisense hotkey thing - one of the
prime reasons I've kept with 'this'. Cheers, m.