By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,911 Members | 1,137 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,911 IT Pros & Developers. It's quick & easy.

Form Naming Convention

P: n/a
Is it common practise to begin the name of form classes with "frm" (e.g.,
frmOneForm, frmAnotherForm).

Or is that generally considered an outdated convention?

If not "frm" what is a common or recommended practise?

Thanks.
Dec 20 '06 #1
Share this Question
Share on Google+
35 Replies


P: n/a
That is an outdated convention.

Class names in .NET should begin with a capital letter, and there should be
no abbreviations.

I'm not sure if there is a recommended practice of having any sort of prefix
in the name of a form.

"Smithers" <A@B.comwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...
Is it common practise to begin the name of form classes with "frm" (e.g.,
frmOneForm, frmAnotherForm).

Or is that generally considered an outdated convention?

If not "frm" what is a common or recommended practise?

Thanks.

Dec 20 '06 #2

P: n/a
"Marina Levit [MVP]" <so*****@nospam.comwrote in message
news:eL**************@TK2MSFTNGP04.phx.gbl...
That is an outdated convention.
Says who...?
Class names in .NET should begin with a capital letter, and there should
be no abbreviations.
Says who...?
Dec 20 '06 #3

P: n/a
"Mark Rae" <ma**@markNOSPAMrae.comwrote in message
news:uJ**************@TK2MSFTNGP02.phx.gbl...
"Marina Levit [MVP]" <so*****@nospam.comwrote in message
news:eL**************@TK2MSFTNGP04.phx.gbl...
>That is an outdated convention.

Says who...?
Says the .NET naming conventions.
http://msdn.microsoft.com/library/de...guidelines.asp
>Class names in .NET should begin with a capital letter, and there should
be no abbreviations.

Says who...?
See above.

The naming conventions are primarily important for code that will be exposed
"to the outside world", and obviously they are advisory, not regulatory.
But when the question is asked, Marina's answer is the correct reply.

Pete
Dec 20 '06 #4

P: n/a
"Peter Duniho" <Np*********@NnOwSlPiAnMk.comwrote in message
news:12*************@corp.supernews.com...
>Says who...?

Says the .NET naming conventions.
http://msdn.microsoft.com/library/de...guidelines.asp
LOL!
Dec 20 '06 #5

P: n/a

Mark Rae wrote:
"Peter Duniho" <Np*********@NnOwSlPiAnMk.comwrote in message
news:12*************@corp.supernews.com...
Says who...?
Says the .NET naming conventions.
http://msdn.microsoft.com/library/de...guidelines.asp

LOL!
I don't get it. What's funny about that?

Dec 20 '06 #6

P: n/a
"Smithers" <A@B.comschrieb:
Is it common practise to begin the name of form classes with "frm" (e.g.,
frmOneForm, frmAnotherForm).

Or is that generally considered an outdated convention?

If not "frm" what is a common or recommended practise?
One possible convention:

Use the suffix 'Form' for all forms typically shown using their 'Show'
method and the suffix 'Dialog' for forms typically shown by calling their
'ShowDialog' method (samples: 'MainForm', 'AboutDialog', 'SettingsDialog').

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Dec 20 '06 #7

P: n/a
"Herfried K. Wagner [MVP]" <hi***************@gmx.atwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...
"Smithers" <A@B.comschrieb:
>Is it common practise to begin the name of form classes with "frm"
(e.g., frmOneForm, frmAnotherForm).

Or is that generally considered an outdated convention?

If not "frm" what is a common or recommended practise?

One possible convention:

Use the suffix 'Form' for all forms typically shown using their 'Show'
method and the suffix 'Dialog' for forms typically shown by calling their
'ShowDialog' method (samples: 'MainForm', 'AboutDialog',
'SettingsDialog').
LOL!

And how is that better than frmMain, fdlgAbout and fdlgSettings...?
Dec 20 '06 #8

P: n/a
"Mark Rae" <ma**@markNOSPAMrae.comschrieb:
>>Is it common practise to begin the name of form classes with "frm"
(e.g., frmOneForm, frmAnotherForm).

Or is that generally considered an outdated convention?

If not "frm" what is a common or recommended practise?

One possible convention:

Use the suffix 'Form' for all forms typically shown using their 'Show'
method and the suffix 'Dialog' for forms typically shown by calling their
'ShowDialog' method (samples: 'MainForm', 'AboutDialog',
'SettingsDialog').

LOL!

And how is that better than frmMain, fdlgAbout and fdlgSettings...?
Mark, it actually isn't much better. It's only more compliant to the naming
guidelines chosen in the .NET Framework's class library. Nothing prevents
you from creating your own naming conventions.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Dec 20 '06 #9

P: n/a

Mark Rae wrote:
"Herfried K. Wagner [MVP]" <hi***************@gmx.atwrote in message
Use the suffix 'Form' for all forms typically shown using their 'Show'
method and the suffix 'Dialog' for forms typically shown by calling their
'ShowDialog' method (samples: 'MainForm', 'AboutDialog',
'SettingsDialog').

And how is that better than frmMain, fdlgAbout and fdlgSettings...?
It complies with a published standard that I feel has more pros and
less cons than Hungarian notation.

Why do you think Hungarian notation is better?

Dec 20 '06 #10

P: n/a
"Herfried K. Wagner [MVP]" <hi***************@gmx.atwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...
>And how is that better than frmMain, fdlgAbout and fdlgSettings...?

Mark, it actually isn't much better. It's only more compliant to the
naming guidelines chosen in the .NET Framework's class library.
Which means not very much...
Nothing prevents you from creating your own naming conventions.
Or even using the ones I've used for the last 20 years or so...
Dec 20 '06 #11

P: n/a
"Brian Gideon" <br*********@yahoo.comwrote in message
news:11*********************@f1g2000cwa.googlegrou ps.com...
Mark Rae wrote:
>"Herfried K. Wagner [MVP]" <hi***************@gmx.atwrote in message
Use the suffix 'Form' for all forms typically shown using their 'Show'
method and the suffix 'Dialog' for forms typically shown by calling
their
'ShowDialog' method (samples: 'MainForm', 'AboutDialog',
'SettingsDialog').

And how is that better than frmMain, fdlgAbout and fdlgSettings...?

It complies with a published standard that I feel has more pros and
less cons than Hungarian notation.
Such as...?
Why do you think Hungarian notation is better?
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...
Dec 20 '06 #12

P: n/a
Mark Rae wrote:
Use the suffix 'Form' for all forms typically shown using their 'Show'
method and the suffix 'Dialog' for forms typically shown by calling their
'ShowDialog' method (samples: 'MainForm', 'AboutDialog',
'SettingsDialog').
And how is that better than frmMain, fdlgAbout and fdlgSettings...?
It's American English. First name / Last name.

--

..NET 2.0 for Delphi Programmers
www.midnightbeach.com/.net
What you need to know.
Dec 20 '06 #13

P: n/a
"Jon Shemitz" <jo*@midnightbeach.comwrote in message
news:45***************@midnightbeach.com...
>And how is that better than frmMain, fdlgAbout and fdlgSettings...?

It's American English. First name / Last name.
And how is that of any use to me...?
Dec 20 '06 #14

P: n/a
Mark Rae wrote:
It's American English. First name / Last name.

And how is that of any use to me...?
Last I checked, even obnoxious guys with slow websites in North London
used the same First name / Last name convention that we do here.

So, an IndividualGroup naming convention feels natural. You look at
it, and right away see how it stands out; you read the whole thing and
see which group it belongs to. In most cases, this is exactly what you
want. You may want to know that you are reading a button's Text
property (after all, that's a lot slower than reading a normal
(field-backed) property) but *which* button is usually more important.

--

..NET 2.0 for Delphi Programmers
www.midnightbeach.com/.net
What you need to know.
Dec 20 '06 #15

P: n/a
"Mark Rae" <ma**@markNOSPAMrae.comwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...
>>And how is that better than frmMain, fdlgAbout and fdlgSettings...?

Mark, it actually isn't much better. It's only more compliant to the
naming guidelines chosen in the .NET Framework's class library.

Which means not very much...
It means quite a lot if your goal is to maintain conformance to the naming
standards other .NET developers are using. Whether you believe it or not,
that *is* a perfectly valid goal, and one shared by a wide variety of
people, especially when dealing with the names of elements of their code
that are exposed for reuse by third parties in the context of .NET.
>Nothing prevents you from creating your own naming conventions.

Or even using the ones I've used for the last 20 years or so...
True enough. What does that have to do with this thread though? The
original poster asked what the "common" or "recommended" practice is, not
what you've been doing for the last 20 years or so.

Pete
Dec 21 '06 #16

P: n/a
"Mark Rae" <ma**@markNOSPAMrae.comwrote in message
news:O9*************@TK2MSFTNGP03.phx.gbl...
>Why do you think Hungarian notation is better?

I've used it successfully for years and years.
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.
It's *really* easy to understand.
Perhaps for you. I didn't find it too hard either. But I certainly have
run into my share of people who have trouble with it. I have spent more
than my share of time in a variety of development teams trying to explain
the correct use of Hungarian to my fellow developers.
It's *really* easy for other people to understand.
See above.
The prefix notation groups all my objects together according to type.
How does it do that? Where do your objects get grouped together according
to type? Why can't you just group them that way by typing them in the
correct order in the first place? And what if you would rather your objects
get grouped together according to some other characteristic.
It makes my life easier.

It allows me to work more efficiently.
All good reasons for you to use it. That has nothing to do with the
original question, nor does it justify your derision of the various replies.
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...
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.

Secondly, there's nothing in the .NET naming conventions that specifically
precludes the use of Hungarian. As I note above, naming a *class* something
like "fdlgAbout" is NOT correct Hungarian notation. A class name like
"About" or "AboutDialog" would be perfectly reasonable Hungarian, and is
also fine for .NET. Specific object instances (locals, parameters, fields,
etc.) are only slightly more problematic and the recommendation for those
(http://msdn2.microsoft.com/en-us/library/ms229004.aspx) are vague enough
that one could use Hungarian notation and still appear to comply with the
spirit of the .NET guidelines.

Finally, the guidelines are just that. Guidelines. They are intended to
enhance code reuse by ensuring that people writing .NET components to be
shared with others all follow a consistent naming convention. And they do
accomplish that. If you never intend to share your code with anyone else,
there's absolutely no reason for you to use a naming convention other than
the one you think is most appropriate.

Your snobbery is entirely out of place here, and not constructive at all.
There are a wide variety of equally useful naming conventions. It's more
important to have *some* naming convention than that the naming convention
be some specific convention. In this case, the .NET naming convention isn't
the one you're familiar with. So what? It doesn't make it worse than the
one you're using...it just makes it different. If you don't like it, don't
use it. It's as simple as that. All of your negative commentary is
unnecessary and irrelevant.

Pete
Dec 21 '06 #17

P: n/a
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!
Dec 21 '06 #18

P: n/a
I use the convention of using Form on the ends of my forms, or
Dialog if it's a dialog, like SettingsDialog, AboutDialog,
ProductForm, etc.

If you have both web forms and windows forms, you can call
them ProductWin and ProductWeb (I think that's the convention;
I don't do web stuff, so can't attest to that for sure).

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.

Robin S.
---------------------------------
"Smithers" <A@B.comwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...
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!

Dec 21 '06 #19

P: n/a
"Smithers" <A@B.comwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...
You can all just ignore Mark Rae. He has a long history in these NGs for
being irrational and emotional...
Hmmm...maybe he doesn't post in the C# newsgroup much? I hadn't noticed him
as being one of the "usual suspects". Oh well...maybe that's the risk of
cross-posting like you did. :)
[...]
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.
Well, if that's so then I'd suggest you might have been more clear in your
original post about that. I certainly didn't get the impression that you
wanted personal coding habits, and as near as I can tell the question you
actually asked has been answered already.
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.
No, it's just another case of a person asking a different question than the
one they really want the answer to. I'm perfectly comfortable with my
naming conventions, even as they continue to be revised over time in
response to a variety of factors, including who I'm coding with, what
language I'm using, and what mood I'm in when I start a project. It
wouldn't bother me at all for someone to criticize something like the naming
convention I use when coding.

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.
For other methods that return a value, I continue to use the Hungarian-style
notation to ensure that the type return value is clearly noted in the method
name. For properties, I have taken to sticking with a simple descriptive
name rather than including any type information, and for any methods that
are implementing functionality that already has a standard naming convention
within .NET (Dispose, Close, OnPaint, etc.) I use the .NET standard even
when it's not strictly necessary (obviously in some cases there's no
choice).

Within a class, I continue to use Hungarian. Field names, variables,
parameters, etc. all get Hungarian style type tags and suffixes (Min, Mac,
Cur, etc.). And I use the convention of putting an underscore to start the
name of any non-public entity.

As far as the type tags go, to a certain extent my use of Hungarian is
simply so that I don't get out of the habit. One of the primary arguments
in favor of Hungarian comes from languages like C or C++ where you may have
defined types that are simply duplicates of some existing built-in type. In
the absence of strict type checking, Hungarian allows one to review the code
and more easily detect type mis-matches. Even in .NET/C# this still comes
up though. For example, I use "x", "dx", and "cx" as variations on an
x-coordinate for a type tag, each with their own specific meaning (absolute
coordinate; delta, always used in relation to some absolute; and a count,
respectively). This is because there's no coordinate type; everything still
uses ints and so there is still the potential for a semantic type mis-match
that the compiler doesn't catch.

But mostly, C# is a very strongly typed language and so there's not really
as much need to worry about mismatching types as the compiler simply won't
let you do it. So I'd admit that in most cases, the Hungarian notation
doesn't serve any purpose. Of course, since it does still serve a purpose
in some very narrow-but-common situations, and since mixing Hungarian and
non-Hungarian doesn't look very nice (and is also prone to errors), that is
in and of itself a justification for using Hungarian.

You'll note that none of the above has anything to do with naming a class.
:) On that topic...

The "flavor" of Hungarian that I originally used involved coming up with
three- or four-letter names for types (with a comment with the type
declaration explaining the abbreviation). The actual type would be
upper-case while the type tag would be exactly the same except lower case.
This was really nice for coming up with and interpreting type tags, but you
often got a lot of similar-looking types, and anything that wasn't
ubiquitous in code risked being misunderstood.

It did have the advantage though that types and variable names were short
and easy to type. It kept the code nice and concise, and it was much
quicker to type code in.

Now with Visual Studio's context-sensitive typing expansion
("intellisense"?), the fact that a type name is lengthy doesn't slow me down
since I almost never have to type the whole thing out anyway (I get really
annoyed when I have to do something in C++ now and don't have the code
editor filling things in for me :) ). So where I used to write something
like:

typedef class DataPerClient
{
...
} DPC, *PDPC, **PPDPC;

using the DPC, PDPC, and PPDPC for declarations and the lower-case versions
for the actual variable, I now just use the "DataPerClient" typename in C#
(and of course, since the concepts of pointers and pointers to pointers has
been covered with a veneer enforced by the language, I don't bother with
anything but the base type in C#). I also don't include base type
information if it's reasonably clear from the name of the class what the
base type or intended variant (such as the "XyzForm is modeless, XyzDialog
is modal" convention) is (which, though I didn't realize it initially, turns
out to be acceptable under the .NET naming guidelines).

Note the initial capital letters, lower-case for each individual word in the
class name. I was using that for my class names long before .NET showed up,
and it's been a fairly common convention for that time as well. It's not
much of a surprise that the .NET guidelines recommend the same thing.

So, does *that* answer the question you meant to ask? :)

Pete
Dec 21 '06 #20

P: n/a
On Wed, 20 Dec 2006 23:15:48 -0800, "RobinS" <Ro****@NoSpam.yah.none>
wrote:
>names seem awfully long to me. ProductNameTextBox seems like
a lot of letters to type.
IntelliType or Visual Assist would help here ;)

Mr.Asm
Dec 21 '06 #21

P: n/a
"RobinS" <Ro****@NoSpam.yah.nonewrote:
>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.
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.

Does it help the programmer to know that the thing is a text box as
he's typing? Not really, because intellisense tells him that.

Does it help the reader? Yes. This is where my naming convention is
weak.

--
Lucian
Dec 21 '06 #22

P: n/a
"Smithers" <A@B.comwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...
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!
Hey Smithers - if my posts bother you so, why don't you just killfile me?
Then I'll never bother you again!
Dec 21 '06 #23

P: n/a
Peter Duniho wrote:
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.
I've had more or less the same experience (I started using hungarian and
then switched gradually to a more C#ish way of doing things) - I'm with
you on the booleans to - IsSomething reads well. It's nice to see the
official guidelines outlined though - I'll have a browse through those.
It doesn't particularly bother me which notation I'm using - as long as
it's consistent that's the main thing (and consistent across multiple
developers' code).

As a side note, one of the sets of third party components I use was
written in Chrome though (not VB or C#) and since Chrome is
case-insensitive the whole Camel Case for protected members and Pascal
Case for public/property members thing goes out the window for them.
They also, I note, continue to use a prefix notation (although not
hungarian) like fMain and uMath (f being for a visual Form and u being
for a Unit of code with no separate designer.cs or .resx file ) - which
is actually kind of handy when you're looking for a Form in a project
that has a lot of files in it - you only have to look through a certain
subset of the files for the one you're after. However, I think they do
that mainly because they build Delphi components as well and it's a
naming convention they've had for years - they don't want to have half
their code using one convention while the rest of their code uses
another... quite logical. So I guess one caveat on the new naming
conventions is that you probably only want to use them for new projects
- the worst of all possible scenarios would be having a project with
mixed naming conventions since, at that stage, they're no longer
conventions at all.

Best Regards,

James Crosswell
Microforge.net LLC
http://www.microforge.net
Dec 21 '06 #24

P: n/a
Peter,

"Peter Duniho" <Np*********@NnOwSlPiAnMk.comschrieb:
>>Why do you think Hungarian notation is better?

I've used it successfully for years and years.

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.
Yes and no. In VB6 and VB 2005 the class name provides access to a form's
default instance.
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.
Well, that's because an increasing number of departments picked up Systems
Hungarian instead of Apps Hungarian.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Dec 21 '06 #25

P: n/a
"Lucian Wischik" <lu***@wischik.comschrieb:
>>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.

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.
For controls I use the type name as /prefix/: 'TextBoxUserName',
'ButtonCancel', ...
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.
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'.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Dec 21 '06 #26

P: n/a
"Herfried K. Wagner [MVP]" <hi***************@gmx.atwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...
[...]
>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.
"Default instance"? Really? I admit, I do very little VB code and when I
do, it's always VBA. Are you saying that every defined class in a VB
program automatically has at least one instance created for it? Or perhaps
this is limited to classes that derive from the Form class?

Either way, ick. That's disgusting.

That unruly behavior notwithstanding, it has nothing to do with what proper
Hungarian is. It just means that a naming convention that attempts to
distinguish between a type declaration and an instance of that type cannot
be completely applied to VB. It's still incorrect Hungarian to name a type
as if it were a variable.
>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.

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.

Pete
Dec 21 '06 #27

P: n/a
"Peter Duniho" <Np*********@NnOwSlPiAnMk.comwrote in message
news:12*************@corp.supernews.com...
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.
I'd be interested to know in which post in this thread you think I actually
said that...

Or, even, which post in this thread I actually mentioned the word
"Hungarian"...
Dec 21 '06 #28

P: n/a

"Herfried K. Wagner [MVP]" <hi***************@gmx.atwrote in message
news:uT**************@TK2MSFTNGP06.phx.gbl...
"Lucian Wischik" <lu***@wischik.comschrieb:
>>>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.

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.

For controls I use the type name as /prefix/: 'TextBoxUserName',
'ButtonCancel', ...
>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.

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

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>
I agree with Herfried. That's one reason I *would* put the
control-type on the end -- so if I change it, I can easily
locate all of them and know that I have changed all the places
where it has been referenced.

Robin S.
Dec 21 '06 #29

P: n/a

Mark Rae wrote:
It complies with a published standard that I feel has more pros and
less cons than Hungarian notation.

Such as...?
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.
>
Why do you think Hungarian notation is better?

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.
I can't argue with any of those.
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...
Well, it's certainly ubiquituous in the Win32 API. But, it's use is
very limited in the .NET BCL. It's seen most often when the .NET API
maps directly to a Win32 API or concept.

Dec 21 '06 #30

P: n/a
"Mark Rae" <ma**@markNOSPAMrae.comwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...
>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.

I'd be interested to know in which post in this thread you think I
actually said that...
Here you go:

"Mark Rae" <ma**@markNOSPAMrae.comwrote in message
news:O9*************@TK2MSFTNGP03.phx.gbl...
[...]
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...
If you aren't talking about the public APIs, you should have said so, since
the entire concept of .NET recommended coding conventions is all about
public APIs. Of course, if you aren't talking about the public APIs, then
I'd be curious why you think you can assert that Microsoft no longer "buys
into it [Hungarian] hook, line and sinker". Whether you're talking about
the public APIs or not, it's a) not true that Microsoft has been a uniformly
Hungarian shop, ever, nor is it true that they no longer predominantly use
Hungarian.

Either way, your claim fails even the most basic sniff test, never mind
close scrutiny.
Or, even, which post in this thread I actually mentioned the word
"Hungarian"...
Who cares if you mentioned the word Hungarian? I never said you did, and
you didn't need to in order to discuss Hungarian.

Pete
Dec 22 '06 #31

P: n/a
For what it's worth...

"Brian Gideon" <br*********@yahoo.comwrote in message
news:11*********************@n67g2000cwd.googlegro ups.com...
It complies with a published standard that I feel has more pros and
less cons than Hungarian notation.

Such as...?

Concerning the convention in general it...

Puts more emphasis on how an identifier is used as opposed to what it
is.
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.
Encourages developers to think of more descriptive names instead of
using abbreviations.
There 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.
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.
This 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).
Reads more like English.
English 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.

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

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.

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

Pete
Dec 22 '06 #32

P: n/a
On Thu, 21 Dec 2006 17:47:17 -0800, "Peter Duniho"
<Np*********@NnOwSlPiAnMk.comwrote:
>For what it's worth...

"Brian Gideon" <br*********@yahoo.comwrote in message
news:11*********************@n67g2000cwd.googlegr oups.com...
>It complies with a published standard that I feel has more pros and
less cons than Hungarian notation.

Such as...?

Concerning the convention in general it...

Puts more emphasis on how an identifier is used as opposed to what it
is.

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.
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?
>Encourages developers to think of more descriptive names instead of
using abbreviations.

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

This 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).
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. In the latter case you're scrolling or entering the
Wid characters anyway.
>Reads more like English.

English 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.
If verbosity can be ambiguous how can some form of abbreviated
verbosity be any less so?
>That 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.
>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.

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.
Agreed. To paraphrase Mr. Einstein keep things as simple as possible
but not so simple as to not work. To think that lpfSomething
simplifies anything is false IMO, pun intended.
>Personally, 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.
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?

regards
A.G.

Dec 22 '06 #33

P: n/a
"Registered User" <n4***@ix.netcom.comwrote in message
news:sq********************************@4ax.com...
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?
Your best bet would be to read Simonyi's original thesis. Don't know if
it's online or not. Google is your friend.
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.
Hungarian has absolutely ZERO to do with pointers. It has just as much
value whether your code uses any pointers or not.

And Hungarian is much more than just about the "stub", as you call it. The
identifier type tag still has nothing to do with pointers, but there are
number of other conventions that Hungarian specifies that have to do with
other portions of an identifier.
>>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.

This 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).
With Intellisense entering the first three or four letters of the
variable name buys you what with hungarian notation?
I specifically wrote "This is a true criticism of Hungarian as it relates to
..NET". I don't disagree that Hungarian can, to some small extent, interfere
with the usability of Intelliense in VS. IMHO, this is an incredibly minor
issue, especially since even the .NET naming conventions have similar
problems, just for different reasons.
You're just at
the start of a large subset where int_Width might be the sixth or
sixtieth element.
"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.
[...]
>>Reads more like English.

English 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.
If verbosity can be ambiguous how can some form of abbreviated
verbosity be any less so?
I never wrote "verbosity can be ambiguous", nor did I write anything that
could be construed that way. Verbosity isn't why English is ambiguous.
[...]
>>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.
Agreed. To paraphrase Mr. Einstein keep things as simple as possible
but not so simple as to not work. To think that lpfSomething
simplifies anything is false IMO, pun intended.
First, it *does* simplify some aspects. Second, certain things about
programming without Hungarian "don't work". Quote Einstein all you like, he
was obviously a smart guy, but he didn't say anything that argues against
using Hungarian (and he wasn't right all the time anyway...none of us are).
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?
The 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.

And the only reason that the latter is beneficial is that that's the
standard used in .NET. IMHO, the benefits of Hungarian *do* outweigh the
benefits of the standard defined by .NET, and the only reason that the
standards defined by .NET win out in the final analysis is that *they* are
the standard for .NET. Since having *some* standards is the most important
aspect of having coding conventions, where coding conventions have already
been defined by some strongly influential entity (like Microsoft, for
example), those standards win out even if there are technical reasons some
other standard might have been better in some respects.

Pete
Dec 22 '06 #34

P: n/a
On Fri, 22 Dec 2006 09:36:55 -0800, "Peter Duniho"
<Np*********@NnOwSlPiAnMk.comwrote:
>"Registered User" <n4***@ix.netcom.comwrote in message
news:sq********************************@4ax.com.. .
>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?

Your best bet would be to read Simonyi's original thesis. Don't know if
it's online or not. Google is your friend.
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 -
>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.

Hungarian has absolutely ZERO to do with pointers. It has just as much
value whether your code uses any pointers or not.
That depends upon the particular standard founded upon Simonyi's
C-based guidelines.

- snip -
>
>You're just at
the start of a large subset where int_Width might be the sixth or
sixtieth element.

"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.
The point remains the same regardless of the notation. I could have
just as easily used lpszFoobar or lpfFoobar.

-snip -
>
I never wrote "verbosity can be ambiguous", nor did I write anything that
could be construed that way. Verbosity isn't why English is ambiguous.
And I never said you did. Properly used verbosity can eliminate
ambiguity. At best terse abbreviations will not create naming
confusion and conflicts.
- snip -
>
First, it *does* simplify some aspects. Second, certain things about
programming without Hungarian "don't work".
Please explain.
>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?

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

regards
A.G.
Dec 22 '06 #35

P: n/a
"Registered User" <n4***@ix.netcom.comwrote in message
news:0n********************************@4ax.com...
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?
>>Hungarian has absolutely ZERO to do with pointers. It has just as much
value whether your code uses any pointers or not.
That depends upon the particular standard founded upon Simonyi's
C-based guidelines.
It's true that there are people going around claiming to be using Hungarian,
when in fact they aren't. But that doesn't in any way detract from the
usefulness of Hungarian.
[...]
>>I never wrote "verbosity can be ambiguous", nor did I write anything that
could be construed that way. Verbosity isn't why English is ambiguous.
And I never said you did. Properly used verbosity can eliminate
ambiguity. At best terse abbreviations will not create naming
confusion and conflicts.
You wrote: "If verbosity can be ambiguous how can some form of abbreviated
verbosity be any less so?"

The question is entirely irrelevant to the text of mine that you quoted,
unless you were implying that I had written "verbosity can be ambiguous".
If it's irrelevant, why did you bother to quote any of my text before making
the question? And why did you ask the question at all? It's not relevant
to what I'm talking about.
>>First, it *does* simplify some aspects. Second, certain things about
programming without Hungarian "don't work".
Please explain.
Simplify: Hungarian makes it simpler to determine the names of identifiers.

"Don't work": without Hungarian, you cannot simply read a line of code and
know whether it "makes sense" from a basic "do the types match up?"
perspective.

These are just examples. I'm not interesting in writing any more essays on
the topic. If you don't like Hungarian, that's fine. But don't go around
saying it's no good, or not useful, when it's clear you haven't really
studied it in the first place.
Is the convention really for the person writing the code or for those
that must follow?
It is for both. Hungarian has a very real benefit for the coder using it.
A person working entirely alone still benefits from the use of Hungarian.
The logic of "the context argues in favor of
different conventions depending on the context" appears rather
circular.
Only because you aren't parsing the sentence correctly. My point is simply
that when there are two competing goals, a single person may wind up
following two different coding standards, depending on the context. In this
case, it means for example that a single person (me, for instance) may use
Hungarian for all code internal to an assembly, and conform to the .NET
conventions for any publicly exposed elements of an assembly.
Shouldn't the benefits of being able to "differentiate the
true semantic usage of an identifier" be available regardless of
context?
It should be. Unfortunately, Microsoft has not offered that as an option
for people coding to comply with their coding conventions for .NET.

Pete
Dec 23 '06 #36

This discussion thread is closed

Replies have been disabled for this discussion.