Form Naming Convention

  • Thread starter Thread starter Smithers
  • Start date Start date
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.

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

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
 
Peter,

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.

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

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

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

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.
 
Mark said:
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.
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.
 
Mark Rae said:
I'd be interested to know in which post in this thread you think I
actually said that...

Here you go:

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

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
 
For what it's worth...

Brian Gideon said:
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
 
For 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.
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?
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.
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.
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.


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

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.
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.
[...]
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
 
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 -
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 -
"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.
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.
 
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.

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