M
MrAsm
names seem awfully long to me. ProductNameTextBox seems like
a lot of letters to type.
IntelliType or Visual Assist would help here

Mr.Asm
names seem awfully long to me. ProductNameTextBox seems like
a lot of letters to type.
RobinS said:For controls, everything I've read recently said to name them
with pascal casing and the control type on the end, but the
names seem awfully long to me. ProductNameTextBox seems like
a lot of letters to type. I, also, would be interested to
learn what others are using for their controls.
You can all just ignore Mark Rae. He has a long history in these NGs for
being irrational and emotional... exuding the kind of resentment commonly
found with those passed over for promotion or recognition many times (yet
still in search of that all-elusive "atta-boy" - undeserved as it may be).
Rather than letting Mark derail this thread, I certainly would have
appreciated a few more ideas for what you all are *actually* doing for
your naming conventions currently. I guess this is another case where
people don't really want to say what they *actually* do because of
emotional guys like Mark Rae criticizing.
Hey Mark - relax, man!
Peter said:As far as what I actually do in C#, I don't have a good answer, as I've only
been doing C# stuff for a year. It's way too early for me to have developed
any solid philosophies on naming conventions specifically for .NET. As it
happens, I do like and use Hungarian and so much of the conventions I use
doing C# code is based on that. Initially, I *only* used Hungarian but then
as I started inheriting from existing .NET classes, that started to result
in some less-than-pleasant-looking juxtapositions where my own methods and
properties showed in various places next to the .NET-style ones.
So lately I've been experimenting with conforming more closely to the .NET
style when writing properties and methods. For the methods, the main
difference here is I have switched from using "F" as the first letter in a
method that returns a boolean value to using the "Is" construct, because
inclusion of the "Is" still makes it clear that I'm dealing with a boolean.
Peter Duniho said:As have many of us. That doesn't make it better. It just makes it
different.
That said, you haven't been using it correctly if you name your *class*
"fdlgAbout". Lower-case type tags are for variables, not type names.
Well, first of all, Microsoft's public APIs have never truly complied with
Hungarian. It's always been a sort of bastardized version, in which much
of the semantic benefits of Hungarian have been removed.
Lucian Wischik said:I omit "TextBox" from the end. If I later decided to change the
control into an editable combo-box then "TextBox" would no longer be
appropriate, so ProductName does seem more generic.
What might "ProductName" be confused with? It won't be confused with
my "business logic" variable, because the TextBox and the underlying
variable are kept in separate places.
Herfried K. Wagner said:[...]That said, you haven't been using it correctly if you name your *class*
"fdlgAbout". Lower-case type tags are for variables, not type names.
Yes and no. In VB6 and VB 2005 the class name provides access to a form's
default instance.
Well, that's because an increasing number of departments picked up Systems
Hungarian instead of Apps Hungarian.
Neither of which are completely correct Hungarian. In any case, the
question isn't *why* the public API doesn't conform to Hungarian. It's
that it *doesn't* and never really has, contrary to Mark's claim.
Herfried K. Wagner said:For controls I use the type name as /prefix/: 'TextBoxUserName',
'ButtonCancel', ...
The problem I am seeing here is that changing a control's type from
textbox to combobox is a breaking change. It would be better to add
an additional property ('ComboBoxProductName') and mark the existing
property as obsolete using 'ObsoleteAttribute'.
Mark said:Such as...?
I've used it successfully for years and years.
It's *really* easy to understand.
It's *really* easy for other people to understand.
The prefix notation groups all my objects together according to type.
It makes my life easier.
It allows me to work more efficiently.
Microsoft themselves bought into it hook, line and sinker (or, at least,
Stan Leszynski's version of it) until relatively recently when someone took
a bit of a disliking to it for no logical reason, AFAICS...
Mark Rae said:I'd be interested to know in which post in this thread you think I
actually said that...
Mark Rae said:[...]
Microsoft themselves bought into it hook, line and sinker (or, at least,
Stan Leszynski's version of it) until relatively recently when someone
took a bit of a disliking to it for no logical reason, AFAICS...
Or, even, which post in this thread I actually mentioned the word
"Hungarian"...
Brian Gideon said:Concerning the convention in general it...
Puts more emphasis on how an identifier is used as opposed to what it
is.
Encourages developers to think of more descriptive names instead of
using abbreviations.
Identifiers in intellisense are sorted by how they are used instead of
what type or type category they belong to. To me anyway, that is a
more logical order.
Reads more like English.
Is what Microsoft uses in the BCL.
Is what most 3rd parties use in their .NET based frameworks.
...that's a few of the important ones on my list.
I've read the last sentence several times and still am uncertain ofFor what it's worth...
This is only true when compared to the bastardized Hungarian seen in the
Windows API. Hungarian was *intended* in fact to focus strongly on *how* an
identifier is used rather than on what it is. One of the major benefits to
using correct Hungarian today is that even when the underlying type is
different, using a correct Hungarian type tag will differentiate the true
semantic usage of an identifier.
Choosing meaningful identifiers is as much a part of writing code asThere is absolutely nothing about Hungarian that precludes the use of
descriptive names, after the type tag. Doing so is common practice among
people who use Hungarian. At the same time, when the use of a descriptive
name would be pointless, Hungarian allows a coder to use an easy, consistent
method for picking identifiers, so that they spend more time writing code
that does stuff and less time worrying about what the right name for an
identifier is.
With Intellisense entering the first three or four letters of theThis is a true criticism of Hungarian as it relates to .NET. However, I
have not found that the alphabetic sorting of identifiers in Intellisense
results in .NET identifiers being grouped any more logically than they would
if they were named using Hungarian. Quite often, closely related names wind
up quite far apart in the list (Left, Right, Top, and Bottom, for example,
or Height and Width, for another...there are numerous similar examples).
If verbosity can be ambiguous how can some form of abbreviatedEnglish turns out not to be a very good way to program. It's too ambiguous,
and that's the very reason that Hungarian is beneficial. It *doesn't* read
exactly like English.
Agreed. To paraphrase Mr. Einstein keep things as simple as possibleThat said, nothing about Hungarian precludes the use of English words in
identifiers. And if your type names are English words, even that part of
the identifier can read like English.
IMHO, these last two are the most important. Conventions *are* important,
and given that Microsoft has made the decision to specify conventions other
than Hungarian for .NET I think it makes a lot of sense to use those
conventions when appropriate.
Absolutely.
But I think it's important to recognize that to large degree, conventions
are arbitrary and it's not necessarily true that one set of conventions is
better than another. Simply that they are different.
For all the hub-bub about naming conventions I don't understand whyPersonally, while I agree that Hungarian may seem more complicated and less
natural language-like, it reality it carries a lot of strong benefits in the
context of programming. There's no fundamental reason that Microsoft
couldn't have standardized their .NET coding conventions on Hungarian (other
than the fact that historically, they haven't seemed to be very successful
doing it properly), and had they done so it'd be my opinion that those
conventions would be just as worthy of following as the ones that are in
place now.
Registered User said:I've read the last sentence several times and still am uncertain of
what meaning it conveys. Is the 'correct' hungarian standard
documented anywhere on the network?
Choosing meaningful identifiers is as much a part of writing code as
anything else. If the name is indeed descriptive what purpose does the
hungarian stub serve? Hungarian notation was extremely useful when
working with pointers directly. Today I see little if any value.
With Intellisense entering the first three or four letters of the
variable name buys you what with hungarian notation?
You're just at
the start of a large subset where int_Width might be the sixth or
sixtieth element.
[...]If verbosity can be ambiguous how can some form of abbreviatedEnglish turns out not to be a very good way to program. It's too
ambiguous,
and that's the very reason that Hungarian is beneficial. It *doesn't*
read
exactly like English.
verbosity be any less so?
[...]Agreed. To paraphrase Mr. Einstein keep things as simple as possibleBut I think it's important to recognize that to large degree, conventions
are arbitrary and it's not necessarily true that one set of conventions is
better than another. Simply that they are different.
but not so simple as to not work. To think that lpfSomething
simplifies anything is false IMO, pun intended.
For all the hub-bub about naming conventions I don't understand why
their value is found only in certain scopes. If a private member is
identified as xyzFoobar why is the public property pointing to that
member named Foobar?
You might have included the referenced sentence.Your best bet would be to read Simonyi's original thesis. Don't know if
it's online or not. Google is your friend.
That depends upon the particular standard founded upon Simonyi'sHungarian has absolutely ZERO to do with pointers. It has just as much
value whether your code uses any pointers or not.
The point remains the same regardless of the notation. I could have"int_Width" is not even close to correct Hungarian, by the way. Not that it
changes what I wrote above, but if you're going to argue against Hungarian,
you should at least learn how to use it first.
And I never said you did. Properly used verbosity can eliminateI never wrote "verbosity can be ambiguous", nor did I write anything that
could be construed that way. Verbosity isn't why English is ambiguous.
Please explain.First, it *does* simplify some aspects. Second, certain things about
programming without Hungarian "don't work".
Is the convention really for the person writing the code or for thoseThe convention used for the private member is for the benefit of the person
writing the code, in that context. The convention used for the public
member is for the benefit of the person incorporating the code into their
*code*, in that context. Even if the person winds up being the same, the
context argues in favor of different conventions depending on the context,
and often those two people are not the same.
Registered User said:You might have included the referenced sentence.
- quote -
One of the major benefits to using correct Hungarian today is that
even when the underlying type is different, using a correct Hungarian
type tag will differentiate the true semantic usage of an identifier.
- end quote -
Why?
That depends upon the particular standard founded upon Simonyi's
C-based guidelines.
[...]And I never said you did. Properly used verbosity can eliminateI never wrote "verbosity can be ambiguous", nor did I write anything that
could be construed that way. Verbosity isn't why English is ambiguous.
ambiguity. At best terse abbreviations will not create naming
confusion and conflicts.
Please explain.
Is the convention really for the person writing the code or for those
that must follow?
The logic of "the context argues in favor of
different conventions depending on the context" appears rather
circular.
Shouldn't the benefits of being able to "differentiate the
true semantic usage of an identifier" be available regardless of
context?