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]

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

I'm not even anti-Hungarian and I don't find this a difficult question.
You name them anything you want, as long as it's reasonably descriptive.
How about "FirstNameLabel" and "FirstNameTextBox" or "FirstNameField"?

Of course, if you're not changing the label text at run-time, you probably
don't care what the name is, and in fact could forego generating the
member field for the control altogether (just disable that in the Designer
for the label). That would be my preference, and then you don't even need
to qualify "FirstName" with a control type or description; you could just
call it "FirstName" and that would be unique and clear enough (for a
program not using Hungarian, anyway ).

Pete

 

[Ronald S. Cook]

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

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.

I'm just not seeing it.

Thanks,
Ron

 

[Peter Duniho]

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

 

[sloan]

Our company policy is "No hungarian, except for GUI/UI components".
As in, actually items "drawn" on a form.
And not a parameter to a procedure.


txtFirstName
lblFirstName
ddlDepartmentList

those are ok.


public void Method1 ( System.Web.UI.TextBox txtTextBox1 )
{}

is not ok.

public void Method1 ( System.Web.UI.TextBox tb)
{}

public void Method1 ( System.Web.UI.TextBox tb1 ,System.Web.UI.TextBox
b2 )
{}

are ok.


This is ~a~ company policy. I'm not saying every company in the work should
do that.

But yeah, I have also found any non hungarian solutions for the UI
components drawn on a page....more cumbersome than its worth.

.......

but as far as code.....i hate hungarian.

int iAge = 18;
instead of
int age = 18;

is unnecessary verbosity IMHO.

...

 

[parez]

Our company policy is "No hungarian, except for GUI/UI components".
As in, actually items "drawn" on a form.
And not a parameter to a procedure.

txtFirstName
lblFirstName
ddlDepartmentList

those are ok.

public void Method1 ( System.Web.UI.TextBox txtTextBox1 )
{}

is not ok.

public void Method1 ( System.Web.UI.TextBox tb)
{}

public void Method1 ( System.Web.UI.TextBox tb1 ,System.Web.UI.TextBox
b2 )
{}

are ok.

This is ~a~ company policy. I'm not saying every company in the work should
do that.

But yeah, I have also found any non hungarian solutions for the UI
components drawn on a page....more cumbersome than its worth.

......

but as far as code.....i hate hungarian.

int iAge = 18;
instead of
int age = 18;

is unnecessary verbosity IMHO.

..

I am not sure if it is ok to post a question on someone else's post..
But I am pretty sure some one will tell me

what about the ui_camelCase or ui_PascalCase? e.g ui_firstName
ui_startDate (this will help if the control changes from ddl to a txt)

is that a good idea? if it is then i would like to reask the same
question, how would i name a label and a text for Name?

 

[sloan]

I tried uiFirstName for about 2 weeks and hated it.

..........

One issue with hungarian is that you run out of prefixes when you prefix
EVERYTHING.

If you have a small known set of ui components....then it kinda works.

txtFirstName
ddlDepartmentList
repMain (repeater)
dgMain (datagrid)
gvMain (gridview)

When is the last time you actually changed a txtDept to a ddlDept?

It happens so rare, its not worth it.

............

 

[Peter Duniho]

[...]
but as far as code.....i hate hungarian.

Don't hate it until you understand it.

int iAge = 18;
instead of
int age = 18;

is unnecessary verbosity IMHO.

The former is not correct Hungarian, whereas the latter actually is (or at
least may be, depending on whether you're consistent about having an "age"
type tag).

As I find myself saying so often in these sorts of threads, the people who
seem to hate Hungarian most vehemently are the same people who don't
actually know how to use Hungarian. They aren't qualified to make a
judgment as to whether Hungarian is useful or proper.

Pete

 

[sloan]

Can you post a link to a "true" hungarian naming convention website?

I am one of those unqualified people apparently.

I guess I haven't used it frequently enough that my memory about it has
suffered.
...

[...]
but as far as code.....i hate hungarian.

Don't hate it until you understand it.

int iAge = 18;
instead of
int age = 18;

is unnecessary verbosity IMHO.

The former is not correct Hungarian, whereas the latter actually is (or at
least may be, depending on whether you're consistent about having an "age"
type tag).

As I find myself saying so often in these sorts of threads, the people who
seem to hate Hungarian most vehemently are the same people who don't
actually know how to use Hungarian. They aren't qualified to make a
judgment as to whether Hungarian is useful or proper.

Pete

 

[Peter Duniho]

Can you post a link to a "true" hungarian naming convention website?

The last time this came up in this newsgroup, I posted a message with
these two links:
http://www.byteshift.de/msg/hungarian-notation-doug-klunder
http://en.wikipedia.org/wiki/Hungarian_notation

You can find the message here:
http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/msg/098f849afc26efd6

In that message, in the context of mentioning the Wikipedia link, I point
out that in my opinion what they is described as "systems" Hungarian is
not Hungarian at all, and is probably one of the biggest reasons most
people don't like Hungarian. Because they think it _is_ Hungarian, and
since "systems" Hungarian is in fact awful and pointless, of course they
come away with the impression that Hungarian itself is awful and pointless.

"Apps" Hungarian is much more appropriate. It's still a specific dialect
and you need not use the "apps"-specific conventions, but inasmuch as
"apps" Hungarian follows the true spirit of Hungarian, it's a good model
to start with.

Of course, you can use Google as well as anyone else to find more threads
in this newsgroup as well as a variety of discussing elsewhere on the web
(keeping in mind that you are likely to come across a fair number of
references that malign Hungarian without really understanding it...keep
your "critical thinking cap" on )

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

 

[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