How name employee first name label and textbox, if not via Hungarian notation?

[Ronald S. Cook]

For all those anti-Hungarian notation people out there, how would you name
an employee first name label and textbox on an create/modify employee form,
respectively (please)?

Thanks,
Ron

[Peter Duniho]

On Mon, 17 Mar 2008 11:03:56 -0700, Ronald S. Cook <rc***@westinis.com>
wrote:

Thanks Pete. My main problem is that, since we abandoned silly
Hungarian notation (against my wishes), we are now naming things as
"FirstNameTextBox" instead of txtFirstName. To me this is just the same
as Hungarian, just post, not pre.. and longer (although one doesn't need
a reference lookup to know txt is for TextBox).

Well, if you need to distinguish between two things that both relate to
"FirstName", you need _something_. Yes, putting the type as that
qualifier does make it seem a lot like Hungarian, but I don't think it's
really doing the same thing. It only provides semantic type information
by coincidence, and mainly it's just allowing you to distinguish from the
label version of the same thing.

In fact, that's why I think that "FirstNameField", or "FirstNameEdit" (to
name another possibility) is just as useful as "FirstNameTextBox". I
would agree that they are not as useful as an actual Hungarian naming
scheme, but it's not like they aren't useful and that naming convention
does serve the purpose of providing immediately readable names (which
addresses the most common complaint against Hungarian).

And as I suggested, in most cases you wouldn't even need a member field
for the Label control, in which case you could leave off the qualifier on
the TextBox control's member field altogether.

By the way, the names I offered as a suggestion would actually only be
suitable for a property, not a field. Following the .NET naming
convention, "camel case" would be appropriate for fields. So
"FirstNameField" becomes "firstNameField", etc.

It just doesn't seem to me that the arguments against Hungarian outweigh
the arguments for it. But Hungarian gets a bad rap as being
mickey-mouse/the old way/not what "real" engineers do.

Well, you won't get any argument from me with respect to the usefulness of
Hungarian. I'm probably one of the last people writing .NET/C# code with
Hungarian. I use it in Java too, in spite of the rabid derision spewed by
certain members of the Java community toward anyone that doesn't follow
Sun's naming convention.

But as useful as I find Hungarian, IMHO it's more important in a team
situation to find a convention that everyone can accept and which is still
reasonably useful. I don't find .NET's conventions as useful as
Hungarian, but they aren't bad either. Being consistent is more important
sometimes than being perfect. :)

Pete

[clintonG]

I absolutely agree with Ronald and have reverted back to Hungarian. The
arguments to abandon Hungarian are fallacious, unsound and pragmatically
wasteful if even at the micro-level, the argument it is what it is and is
what it was; a terrible idea imposed by shallow minded thinkers presuming
the use of Intellisense would prove sufficient. Worse yet, when proven how
illogical their fallacy they usually skulk away in denial or pull rank while
sniffing their haughty nose in the air.

<%= Clinton Gallagher

"Peter Duniho" <Np*********@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...

On Mon, 17 Mar 2008 11:03:56 -0700, Ronald S. Cook <rc***@westinis.com>
wrote:

>Thanks Pete. My main problem is that, since we abandoned silly
Hungarian notation (against my wishes), we are now naming things as
"FirstNameTextBox" instead of txtFirstName. To me this is just the same
as Hungarian, just post, not pre.. and longer (although one doesn't need
a reference lookup to know txt is for TextBox).

Well, if you need to distinguish between two things that both relate to
"FirstName", you need _something_. Yes, putting the type as that
qualifier does make it seem a lot like Hungarian, but I don't think it's
really doing the same thing. It only provides semantic type information
by coincidence, and mainly it's just allowing you to distinguish from the
label version of the same thing.

In fact, that's why I think that "FirstNameField", or "FirstNameEdit" (to
name another possibility) is just as useful as "FirstNameTextBox". I
would agree that they are not as useful as an actual Hungarian naming
scheme, but it's not like they aren't useful and that naming convention
does serve the purpose of providing immediately readable names (which
addresses the most common complaint against Hungarian).

And as I suggested, in most cases you wouldn't even need a member field
for the Label control, in which case you could leave off the qualifier on
the TextBox control's member field altogether.

By the way, the names I offered as a suggestion would actually only be
suitable for a property, not a field. Following the .NET naming
convention, "camel case" would be appropriate for fields. So
"FirstNameField" becomes "firstNameField", etc.

>It just doesn't seem to me that the arguments against Hungarian outweigh
the arguments for it. But Hungarian gets a bad rap as being
mickey-mouse/the old way/not what "real" engineers do.

Well, you won't get any argument from me with respect to the usefulness of
Hungarian. I'm probably one of the last people writing .NET/C# code with
Hungarian. I use it in Java too, in spite of the rabid derision spewed by
certain members of the Java community toward anyone that doesn't follow
Sun's naming convention.

But as useful as I find Hungarian, IMHO it's more important in a team
situation to find a convention that everyone can accept and which is still
reasonably useful. I don't find .NET's conventions as useful as
Hungarian, but they aren't bad either. Being consistent is more important
sometimes than being perfect. :)

Pete

[clintonG]

I absolutely agree with Ronald and have reverted back to Hungarian. The
arguments to abandon Hungarian are fallacious, unsound and pragmatically
wasteful if even at the micro-level, the argument it is what it is and is
what it was; a terrible idea imposed by shallow minded thinkers presuming
the use of Intellisense would prove sufficient. Worse yet, when proven how
illogical their fallacy they usually skulk away in denial or pull rank while
sniffing their haughty nose in the air.

D.) All of the above.

<%= Clinton Gallagher

"Peter Duniho" <Np*********@nnowslpianmk.comwrote in message
news:op***************@petes-computer.local...

On Mon, 17 Mar 2008 11:03:56 -0700, Ronald S. Cook <rc***@westinis.com>
wrote:

>Thanks Pete. My main problem is that, since we abandoned silly
Hungarian notation (against my wishes), we are now naming things as
"FirstNameTextBox" instead of txtFirstName. To me this is just the same
as Hungarian, just post, not pre.. and longer (although one doesn't need
a reference lookup to know txt is for TextBox).

Well, if you need to distinguish between two things that both relate to
"FirstName", you need _something_. Yes, putting the type as that
qualifier does make it seem a lot like Hungarian, but I don't think it's
really doing the same thing. It only provides semantic type information
by coincidence, and mainly it's just allowing you to distinguish from the
label version of the same thing.

In fact, that's why I think that "FirstNameField", or "FirstNameEdit" (to
name another possibility) is just as useful as "FirstNameTextBox". I
would agree that they are not as useful as an actual Hungarian naming
scheme, but it's not like they aren't useful and that naming convention
does serve the purpose of providing immediately readable names (which
addresses the most common complaint against Hungarian).

And as I suggested, in most cases you wouldn't even need a member field
for the Label control, in which case you could leave off the qualifier on
the TextBox control's member field altogether.

By the way, the names I offered as a suggestion would actually only be
suitable for a property, not a field. Following the .NET naming
convention, "camel case" would be appropriate for fields. So
"FirstNameField" becomes "firstNameField", etc.

>It just doesn't seem to me that the arguments against Hungarian outweigh
the arguments for it. But Hungarian gets a bad rap as being
mickey-mouse/the old way/not what "real" engineers do.

Well, you won't get any argument from me with respect to the usefulness of
Hungarian. I'm probably one of the last people writing .NET/C# code with
Hungarian. I use it in Java too, in spite of the rabid derision spewed by
certain members of the Java community toward anyone that doesn't follow
Sun's naming convention.

But as useful as I find Hungarian, IMHO it's more important in a team
situation to find a convention that everyone can accept and which is still
reasonably useful. I don't find .NET's conventions as useful as
Hungarian, but they aren't bad either. Being consistent is more important
sometimes than being perfect. :)

Pete