Why not just GoneBad? The naming standard for local, private variables
may have been stated somewhere is MS's guidelines, but I haven't found
it yet. But, in light of the fact that they say to use PascalCase for
*everything* in their spec except for parameters, I just use this style
for private variables as well.
In fact, if you name your private variable goneBad, you would be
rendering as useless the camelCase parameter naming convention. The
whole point of having only parameters be camelCase is that you can
identify at-a-glance variables that have been passed into a method. But
if you dimention new variables within the method using camelCase, you've
lost this benefit.
In regards to your "GoneBad", I've adopted what seems to be a common
convention of prefixing Boolean variables with "Is" or "Has". As in,
IsClosed or HasGoneBad. Maybe that's a little too close to Hungarian
notation, but it brings a certain level of consistency to the code.
- Mitchell S. Honnert
Oh, the only reason I do it for local variables is for easier
identification. It's easier to seperate out:
goneBad
than it is to seperate out:
gonebad
Herfried, I don't read German, so I haven't read your article, but I
do
have
a question about your first summarized point...
* Distinction of two identifiers (property, backing field) by case
only
can
lead to bugs in the implementation which cannot be easily
detected.
As far as I can tell, the only place in the .NET naming standard where
it
says to use camelCase is for parameters. (I think there may be have
been
one other variable type where they recommended camelCase, but if I
remember
correctly, it was very rarely used.) So, the point you are making
doesn't
appear to apply MS's naming standards.
In other words, MS never says to use camelCase for "backing field"
variables, as in the example...
Private firstName As String
At least, it never says it on any official MS web page that I have
found.
Here's where I have been looking.
http://msdn.microsoft.com/library/d...en-us/cpgenref/html/cpconnamingguidelines.asp
Is there some other reference that you are using? Do you have a
particular
link that says to use camelCase for variables other than parameters?
(I've
seen camelCase used inconsistently in MS's own VB.NET sample code, but
this
probably has more to do with the authors of the sample code being C#
people
than evidence of any particular naming standard.)
The problem I have is that MS states explicitly what naming convention
to
use for Classes, Namespaces, Parameters, Methods, and Properties, but
as
far
as I can tell, they don't say how to name private member variables
like
the
private "backing field" for a property. I use a "p_" prefix to
differentiate these private member variables as those used by
properties,
but this is just my convention that I use for lack of being able to
find
anything definitive from MS.
Regards,
- Mitchell S. Honnert
: > So after three years of working in .NET and stubbornly holding
on
to
my
: > old hungarian notation practices--- I resolved to try to rid
myself
of
: > the habit. Man, I gotta say that it is liberating!!! I love it.
:
: Well, I do not use type prefixes ("Systems Hungarian") because I
use
: 'Option Strict On' most of the time. However, I use type
prefixes
when
: dealing with late binding (variables typed as 'Object').
Additionally
: I use the 'm_' prefix to mark private fields, and I tend to use
Apps
: Hungarian because it still makes sense in strictly-typed
languages.
:
: On a side note: I still refuse to use camel case for the reasons
listed
: in <URL:
http://dotnet.mvps.org/dotnet/articles/camelcase/>
(German
: article!).
Could you summarize the points being raised in this article for
those
of
us
who don't read German? Thanx,
The points made in the article are:
* Distinction of two identifiers (property, backing field) by case
only
can
lead to bugs in the implementation which cannot be easily
detected.
* By naming the property using pascal case and the backing field
using
camel case it's harder to visually detect that both belong to
each
other.
This argument is based on a human visual character recognition
model.
* The naming rules described in the .NET Framework Design
Guidelines
and the internal Guidelines published by Brad Abrams [MSFT]
cannot be
applied to VB.NET because VB.NET is not case-sensitive.
* The first character of a word/sentence serves an important role
for
word recognition. In classic typography the first letter has
often
been
written in upper-case and sometimes ornamented to underline its
importance. By starting identifiers' names with a lower-case
letter
while using upper-case letters inside the identifier this long
tradition
in typography is obeyed.
* Most naming guidelines are made by developers only instead of
consulting developers, psychologists, linguists, etc. who have
the
scientific background to optimize naming guidelines.
