Best practice for naming controls

[Guest]

Is it okay to have controls on more than one form with the same name? For
example, a Name_ID text box on three different forms? Or must each control
name be unique?

Does this practice violate good design technique? What is best practice?

Thanks much in advance.

 

[Dirk Goldgar]

In

Is it okay to have controls on more than one form with the same name?
For example, a Name_ID text box on three different forms?

Yes, that's fine. You'll find disagreement among professionals as to
what are "best practices", and some do like to name fields with a
table-identifying prefix or suffix so that each field name is unique to
a particular table. I don't do it that way myself, and don't consider
it a "best practice", but some of my colleagues do.

I would consider it best practice that each bound control on a form or
report should have a name that relates to the field it's bound to. Some
believe the control name should never be the same as the actual field
name, but rather should be prefixed or suffixed to identify the type of
control. I disagree with that, but I'm probably in the minority.

Even if you name each table field uniquely, and follow such a convention
about control names, that doesn't mean that you can't have controls on
different forms that are bound to the same field in the same table, so
you can still have duplicate control names in your application. So it's
not worth fretting over. I can't imagine any circumstance where there
could be any ambiguity over which control, on which form, you might be
referring to.

 

[Allen Browne]

Using the same control name on different forms will cause no problems.

More pedantic people sometimes prefer to have field names that are different
from any other field names in the entire application, but there is no
problem using the same field names in different tables. In fact, it can be
useful (e.g. where a foreign key matches the name of the primary key in the
lookup table.)

There are field names that can cause problems, e.g. Name and Date. Here's a
list to avoid when you are creating tables:
http://allenbrowne.com/AppIssueBadWord.html

 

[OldPro]

Is it okay to have controls on more than one form with the same name? For
example, a Name_ID text box on three different forms? Or must each control
name be unique?

Does this practice violate good design technique? What is best practice?

Thanks much in advance.

Dittos on Allen's and Dirk's replies. In addition I would like to add
a reccomendation to distinguish fields in a table from memory
variables from controls on a form. If the field name is FirstName,
then I usually call the variable sFirstName (so I know it is a string)
and the control txtFirstName (so I know it is a textbox). I also do
it so that I don't accidentally reference the wrong thing with the
same name; it is better to be sure.

 

[Guest]

Dirk
I am one who would disagree with you on naming a control the same as the
field to which it is bound. It is rare, but in a couple of circumstances, I
have seen it cause ambiguity. In addition, I find code much easier to read
when a naming convention is used the indicates the nature of the entity.

 

[Dirk Goldgar]

In

Dirk
I am one who would disagree with you on naming a control the same as
the field to which it is bound. It is rare, but in a couple of
circumstances, I have seen it cause ambiguity. In addition, I find
code much easier to read when a naming convention is used the
indicates the nature of the entity.

Dave -

With luck, we'll argue it over a beer sometime soon.

 

[Guest]

Are you buying

Not intended as a disagreement. Just an FYI.

 

[Tony Toews [MVP]]

and some do like to name fields with a
table-identifying prefix ... so that each field name is unique to
a particular table. I don't do it that way myself, and don't consider
it a "best practice", but some of my colleagues do.

Dirk is politely referring to me. <smile>
Tony's Table and Field Naming Conventions
http://www.granite.ab.ca/access/tablefieldnaming.htm

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Guest]

Cool, Now the three of us can get together, drink some beer, and start a
barroom brawl (From my experience in Canada, this is only second in
popularity to Hockey, but then no surprise, the only difference between a
Hockey game and a barroom brawl is the beer

 

[David W. Fenton]

I would consider it best practice that each bound control on a
form or report should have a name that relates to the field it's
bound to. Some believe the control name should never be the same
as the actual field name, but rather should be prefixed or
suffixed to identify the type of control. I disagree with that,
but I'm probably in the minority.

If it's a minority, I'm in it with you. I only change the control
names from their default (i.e., the same as the controlsource) when
I need to refer to the control (or the controlsource field in the
recordsource) in code. At that point, I need to use the field or the
control, and they have different properties, so it's crucial that
one disambiguates with one's name.

The question makes me think of the people who insist that a field
name should never used twice in a database, that all tables should
have unique field names. To me, this violates relational integrity,
as you end up with the same data under two different names, as in a
foreign key will end up with a name that is different from the PK it
is related to.

I also re-use these field names in all tables:

Created
Updated
UpdatedBy

It leads to issues when you need both tables in a single form, but
then I just alias the fields in that particular recordsource (and
the logic gets convoluted anyway because you've got to make sure
that you update those fields for the right tables -- in that case,
the aliasing is the least of the complications!).

I think it's really a question very much like this one:

Should I re-use a filename in my C:\Documents folder that I'm
already using in my C:\Data folder?

In that context, it looks like a silly question, since the files are
disambiguated by their containing folder. To me, the control name
and field name questions are exactly the same, as they have
different containing objects, so there's no danger of collision.

Now, one could make the argument that when you join two tables in a
recordsource that have fields with the same names, you have
collisions, and that's true (though I don't see why it bothers
anyone at all), but there is no corresponding situation with forms
where that can happen (you can't join two forms into one in the same
way you can join two tables in SQL).

So, even the argument for unique field names in all tables in a
database (with which I disagree) is not a logical basis for having
unique control names application-wide.

 

[David W. Fenton]

In addition I would like to add
a reccomendation to distinguish fields in a table from memory
variables from controls on a form. If the field name is
FirstName, then I usually call the variable sFirstName (so I know
it is a string) and the control txtFirstName (so I know it is a
textbox). I also do it so that I don't accidentally reference
the wrong thing with the same name; it is better to be sure.

Hmm. I don't know why you'd have that problem. Variables have no
parent, but controls and fields do (Me). So, you could have:

Me!FirstName

Now, there are completely different reasons to distinguish the
control from the underlying field name (because the default
collection of Me is a combination of the Fields Collection and the
Controls Collection), and if you need to refer to either of them in
code, you need to disambiguate their names. I use:

Me!FirstName

and

Me!txtFirstName

But there is simply no collision with variable names *unless* you
are skipping specifying the parent (i.e., Me! or Me.), which I'd
strenuously recommend against (even though you can very often get
away with it because Access guesses correctly for you).

The reason for using prefixes on variables is not to disambiguate,
but to identify for the programmer the data type of the variable in
question. I think that's a different issue, and others don't do
that.

But I doubt anyone fails to distinguish fields and controls when
they need to refer to them in code (if you don't, you're bound to
run into problems!).

 

[Tony Toews [MVP]]

Cool, Now the three of us can get together, drink some beer, and start a
barroom brawl (From my experience in Canada, this is only second in
popularity to Hockey, but then no surprise, the only difference between a
Hockey game and a barroom brawl is the beer

And the ice. Hockey has ice. Bar rooms generally don't have such.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Guest]

Oh, yeah, ice... I forget about the ice, but I live in Fort Worth, Texas.
What would I know about ice

 

[Rick Brandt]

I would consider it best practice that each bound control on a
form or report should have a name that relates to the field it's
bound to. Some believe the control name should never be the same
as the actual field name, but rather should be prefixed or
suffixed to identify the type of control. I disagree with that,
but I'm probably in the minority.

If it's a minority, I'm in it with you. I only change the control
names from their default (i.e., the same as the controlsource) when
I need to refer to the control (or the controlsource field in the
recordsource) in code. At that point, I need to use the field or the
control, and they have different properties, so it's crucial that
one disambiguates with one's name. [snip]

"Crucial" is a bit strongly worded there since I never change the name and
have never had a single instance where it was a problem. Access seems
perfectly capable of knowing whether the reference is to the field or the
contriol when you refer to a property that only one of them has.

 

[Tony Toews [MVP]]

Oh, yeah, ice... I forget about the ice, but I live in Fort Worth, Texas.
What would I know about ice

<smile> I think there's a NHL hockey team in Tampa, Florida. I've
never quite figured out why.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[David W. Fenton]

I would consider it best practice that each bound control on a
form or report should have a name that relates to the field it's
bound to. Some believe the control name should never be the
same as the actual field name, but rather should be prefixed or
suffixed to identify the type of control. I disagree with that,
but I'm probably in the minority.

If it's a minority, I'm in it with you. I only change the control
names from their default (i.e., the same as the controlsource)
when I need to refer to the control (or the controlsource field
in the recordsource) in code. At that point, I need to use the
field or the control, and they have different properties, so it's
crucial that one disambiguates with one's name. [snip]

"Crucial" is a bit strongly worded there since I never change the
name and have never had a single instance where it was a problem.
Access seems perfectly capable of knowing whether the reference is
to the field or the contriol when you refer to a property that
only one of them has.

I don't believe in depending on Access to guess correctly 100% of
the time, just as I try not to depend on implicit type coercion.