J
Jonathan Wood
Camel case refers to capitalizing the first letter of each subword except
for the first one.
Examples:
camelCase
destinationUrl
thisIsCamelCase.
for the first one.
Examples:
camelCase
destinationUrl
thisIsCamelCase.
J
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.
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.
G
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.
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.
G
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.
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.
J
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.
read anyone who used the term camel case to describe that convention.
G
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.
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.
H
Hans-J. Ude
Jonathan Wood said:
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
G
Guest
The compiler understands it perfectly and assigns to the field myInt, the
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.
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 hasexecuted 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.
J
Jonathan Wood
Mark,
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.
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
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.
G
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.
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.
D
Dave Sexton
Hi Michael,
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
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
Michael Nemtsev said:
D
Dave Sexton
Hi Jonathan,
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)
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)
J
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.
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.
D
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
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
D
Dave Sexton
Hi Hans,
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.
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.
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.
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.
D
Dave Sexton
Hi Jonathan,
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?
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?
J
Jonathan Wood
Dave,
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 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.
D
Dave Sexton
Hi Jonathan,
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
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
J
Jonathan Wood
Dave,
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 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.
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.
C
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
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