Member Variables Naming Convention

[Jonathan Wood]

Camel case refers to capitalizing the first letter of each subword except
for the first one.

Examples:

camelCase
destinationUrl
thisIsCamelCase.

 

[Jonathan Wood]

Ack! I don't like that at all. What about myInt = myInt + myInt? I mean,
I've never *ever* seen anyone do this. I'll just have to take your word for
it that it actual works (it doesn't seem like it could). But I would avoid
this approach like the plague.

Thanks.

 

[Guest]

Hi Dave,
I would say it is "not essential" rather than "not necessary", indeed the
code will work without the this. prefix in the third case but I consistently
use "this." to access all of my class fields throught my code so that I can
distinguish between local variables and class fields easily

Mark.

 

[Guest]

There are different flavours of camel casing too, most commenly camel case
refers to lower camel case i.e. thisIsLowerCamelCase, however there is also
upper camel case ThisIsUpperCamelCase which is also referred to as Pascal
case.

Mark.

 

[Jonathan Wood]

I have only seen the second example referred to as Pascal case. I've yet to
read anyone who used the term camel case to describe that convention.

 

[Guest]

I don't believe it is very common usage, one of the professors at my uni
used to use that term, but apart from him not heard anyone else use it and
seems like wikipedia also has comments on this (believe it as you will ):

http://en.wikipedia.org/wiki/Camel_case

Mark.

 

[Hans-J. Ude]

Camel case refers to capitalizing the first letter of each subword except
for the first one.

Examples:

camelCase
destinationUrl
thisIsCamelCase.

Thanks for the info everbody. I'm new to C# and as an old MFC
programmer I'm very accustomed to the "m_" and "CMyClass" convention.
I begin liking C# and consider to learn it better. Since I'm at the
beginning right now I don't want to "learn" any mistakes which are
hard to get rid of later. In another post in this thread Jonathan
writes "It appears Microsoft now recommends not using an m_ or _
prefix." I wouldn't care much about what Microsoft recommends or not,
this "m_" style simply makes sense for me. When I take a look at the
ScreenSaver and MovieCollection samples I see they are usig that
"camel case" convention. I must admit that I find it ugly, but that's
probably because i'm not used to read and write it.

Hans

 

[Guest]

The compiler understands it perfectly and assigns to the field myInt, the

value of the parameter myInt.

Not true, if you have:

class Person
{
private string name;

public Person(string name)
{
name = name;
}
}

Then the compiler will simply assign the local variable name to itself, you
will get a warning about this (hopefully an error since nobody would leave
the "treat warning as error" option unchecked ), after the constructor has
executed the class field "name" is still null.

This is also very confusing, the "this." is required. Also in the case below:

class Person
{
private string name;

public Person(string name)
{
name = name;
}

public void DoSomething(string name)
{
string finalName = name + "xyz";
}
}

The compiler does not give any warning about the possible ambiguity of the
variable named "name", did you mean to use the local variable or the class
field but forgot the this. prefix, from what I can tell this is possibly a
case against using the this. notation.

Mark.

 

[Jonathan Wood]

Mark,

Not true, if you have:

class Person
{
private string name;

public Person(string name)
{
name = name;
}
}

Then the compiler will simply assign the local variable name to itself,
you
will get a warning about this (hopefully an error since nobody would leave
the "treat warning as error" option unchecked ), after the constructor
has
executed the class field "name" is still null.

You know, I would've sworn that was the case. But since I have no tested it
directlyed, I was not comfortable saying Dale was wrong. I figured he tried
it out.

As far as I'm concerned, this should not work and should be avoided even if
it did work.

 

[Guest]

Hi Jonathan,
I agree, I am not sure why self assignment is legal, maybe there is some
perfectly good case for it, I can't think of any though.

Mark.

 

[Dave Sexton]

Hi Michael,

Maybe not quite undestand u - it provides anything, just mark that we deal with private/property
item.

Any other ideas how to underpin this?

Well, "_" doesn't seem to provide any value that doesn't exist using the standard notation. If I
see something like, "firstNumber" in a method body it's usually obvious to me whether its a field or
a parameter just by quickly scanning the method, considering that the method was properly designed
to be succinct, or even just by context and its chosen name. In larger methods a simple mouse-over
does the trick. Intellisense tells us when a variable is a "local variable" (although I rarely even
need that information from intellisense, if ever). Otherwise, when "(local variable)" isn't
displayed, it's a field. And, if an object is confusing to the point where something such as
"firstNumber" isn't obviously a field or a local variable, then the chosen name might not be
descriptive enough.

So the best argument for "_" so far is that it alleviates parameter ambiguity without requiring
"this.", which I actually prefer over "_" anyway. Furthermore, "this." has been standardized while
"_" is not recommended by Microsoft.

--
Dave Sexton

Hello Dave,
DS> But other than the example above, does an "_" prefix provide any
DS> value?

Maybe not quite undestand u - it provides anything, just mark that we deal with private/property
item.

Any other ideas how to underpin this?

---
WBR,
Michael Nemtsev [C# MVP] :: blog: http://spaces.live.com/laflour

"At times one remains faithful to a cause only because its opponents do not cease to be insipid."
(c) Friedrich Nietzsche

 

[Dave Sexton]

Hi Jonathan,

Actually, in the Microsoft guidelines, it really is.

No, it's really not

Care to show me where Microsoft says that controls shouldn't be named with prefixes such as "txt" or
"lbl"?

(They are stored as private fields, you know)

 

[Jonathan Wood]

Well I was going to look that up again but I see you gave me a trick
question. I just stated in the post you were replying to that I considered
references to controls a bit different than straight variables. Perhaps you
didn't read my entire post, eh? We were talking about member variables.

 

[Dave Sexton]

Hi Mark,

I don't and I've never had a problem. I use "this." when it's required by the compiler to qualify a
reference, otherwise I just reference the field directly.

I have nothing against "this." since it can only makes things clearer when present, but I opt for
less typing

 

[Dave Sexton]

Hi Hans,

I wouldn't care much about what Microsoft recommends or not,
this "m_" style simply makes sense for me

Following standards provides real value through consistency. Not following any standards makes
development harder by creating friction when moving amongst different notations and conventions.
Making up your own standards makes interoperability harder, inevitably making development harder as
well - even if its not harder for you it will be for someone else one day that has to work with your
atypical code.

I must admit that I find it ugly, but that's
probably because i'm not used to read and write it.

Yes, it is ugly if you're used to something else. I think the ugliness factor is the number one
reason for introducing legacy standards into modern, standardized code, although it definitely isn't
the only reason.

 

[Dave Sexton]

Hi Jonathan,

Well I was going to look that up again but I see you gave me a trick question. I just stated in
the post you were replying to that I considered references to controls a bit different than
straight variables. Perhaps you didn't read my entire post, eh? We were talking about member
variables.

I read your entire post. No tricks here

We are talking about fields (member variables, as you say), which txtFirstName and lblFirstName
certainly are.

How would you name these two Controls?

 

[Jonathan Wood]

Dave,

I read your entire post. No tricks here

We are talking about fields (member variables, as you say), which
txtFirstName and lblFirstName certainly are.

How would you name these two Controls?

Well, as I indicated, I consider that a different issue. I haven't decided
on this issue for sure, but I have a tendancy to stick with what I did in
VB, which is to include those prefixes.

 

[Dave Sexton]

Hi Jonathan,

Well, as I indicated, I consider that a different issue. I haven't decided on this issue for sure,
but I have a tendancy to stick with what I did in VB, which is to include those prefixes.

I don't see it as a different issue at all. They are fields. (but the point is a moot one anyway
since you were right...)

BTW, I found two interesting bullets in a Microsoft document [link below] regarding the use of
hungarian notation and the "_" prefix in field names:

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

I must argue here that my examples of txtFirstName and lblFirstName indicate both type and
semantics. However, I use the notation in other controls even when there is no ambiguity, but I'm
going to try to break that habit for my next project. Do I really need to know that a field is a
Control by looking at its name when I have intellisense and tooltips on hand at all times? - I
don't think so, but I'll see how it goes

- 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.

"Field Usage Guidelines [.NET Framework]"
http://msdn.microsoft.com/library/d...html/cpconfieldusageguidelines.asp?frame=true

 

[Jonathan Wood]

Dave,

BTW, I found two interesting bullets in a Microsoft document [link below]
regarding the use of hungarian notation and the "_" prefix in field names:

Yeah, those were the ones I was thinking about. Microsoft is being very
one-sided about not using those prefixes. If you see where they talk about
control names, please pass it along.

I must argue here that my examples of txtFirstName and lblFirstName
indicate both type and semantics. However, I use the notation in other
controls even when there is no ambiguity, but I'm going to try to break
that habit for my next project. Do I really need to know that a field is
a Control by looking at its name when I have intellisense and tooltips on
hand at all times? - I don't think so, but I'll see how it goes

I think it is still useful. Yes, Intellisense offers assistance here but I
often print code and review it in more detail. Also, for more complex code,
it may just be more efficient to know what a variable refers to just by
looking.

In the end, I have mixed feelings about this. I'm all for cleaning things
up, but I've been programming a long, long time and readability is
important. I'm not 100% sure I'm ready to abandon prefixes that tell me
about a particular variable.

 

[Cor Ligthert [MVP]]

Jonathan,

I just find that underscore hard to read in some situation.

While it is in my idea not on the most nice place on the keyboard for those
who are using 10 fingers to type.

Very good to create RSI.

Cor