命名惯例澄清 [英] Naming convention clarification

问题描述

尊重Stan Leszynski和Greg Reddick，我仍然想知道如何在我的Access MDB中对表单上的控件进行命名。


如果我错了，请纠正我...


如果表单上的文本框或其他控件被*绑定到名为
的表字段
FullName，然后它应该*不*被命名为txtFullName，而是仅仅

FullName - 也就是说，表单上文本框的名称应始终为

*与它所绑定的表字段*的名称相同。并且由于表格

字段名称应保持独立于其数据类型，因此无需使用

txt，dtm，int或任何其他前缀。


听起来是对的吗？

With all due respect to Stan Leszynski and Greg Reddick, I''m still wondering
how to name controls on forms in my Access MDB.

Correct me if I''m wrong...

If a textbox or other control on a form is *bound* to a table field named
"FullName", then it should *not* be named "txtFullName", but rather just
"FullName" - that is, the name of the textbox on a form should always be the
*same as the name of the table field* it''s bound to. And because the table
field name should remain independent of its data type there''s no need to use
txt, dtm, int or any other prefix.

sound about right?

推荐答案

除非您正在与团队合作并且必须遵守团队规则，否则找一个系统

适合你。


对我来说，让绑定控件的Name和ControlSource相同工作

罚款，但不受约束字段得到前缀。


使用ControlSource中不同的名称是你可以

然后轻松区分表格上的控件和字段在

RecordSource中。例如，控件具有Visible属性，但字段

不具有。关键方面是保持一致：如果你给Field指定一个新值

（命名与控件不同），你可能看不到新的

值。控制直到保存记录（此时访问

更新控件）。


似乎没有多少人在表级使用字段名称的前缀。

虽然有一些观点：当你在SQL字符串中嵌入文字时，文本和日期/时间字段需要

分隔符，并且当

构建表单过滤器，OpenReport的WhereCondtions，第3个文件
DLookup（）等的



-

Allen Browne - 微软MVP。西澳大利亚州珀斯。

访问用户提示 - http：// allenbrowne.com/tips.html

回复群组，而不是mvps dot org的allenbrowne。


" deko" <无**** @ hotmail.com>在消息中写道

新闻：OX ******************* @ newssvr25.news.prodigy。 com ...

Unless you are working with a team and must follow team rules, find a system
that suits you.

For me, having the Name and ControlSource the same for bound controls works
fine, but unbound fields get the prefix.

The point of using a different Name from the ControlSource is that you can
then easily distinguish between the Control on the Form and the Field in its
RecordSource. For example, the control has a Visible property, but the Field
does not. The crucial aspect is to be consistent: if you assign a new value
to the Field (named differently than the control), you may not see the new
value in the control until the record is saved (at which point Access
updates the control).

Not many people seem to use prefixes for field names at the table level.
There is some point to it though: Text and Date/Time fields require
delimiters when you embed literals in a SQL string, and this crops up when
building filters for forms, WhereCondtions for OpenReport, the 3rd agument
for DLookup(), etc.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"deko" <no****@hotmail.com> wrote in message
news:OX*******************@newssvr25.news.prodigy. com...

尽管Stan Leszynski和Greg Reddick非常尊重，我仍然想知道如何在我的Access MDB中对表单上的控件进行命名。

如果表单上的文本框或其他控件被*绑定到名为
FullName的表字段，那么它应该*不*命名为txtFullName，而只是
FullName - 也就是说，表单上文本框的名称应始终为
*与它所绑定的表字段*的名称相同。并且因为
表字段名称应保持独立于其数据类型，所以不需要
使用txt，dtm，int或任何其他前缀。

听起来是正确的？

With all due respect to Stan Leszynski and Greg Reddick, I''m still wondering how to name controls on forms in my Access MDB.

Correct me if I''m wrong...

If a textbox or other control on a form is *bound* to a table field named
"FullName", then it should *not* be named "txtFullName", but rather just
"FullName" - that is, the name of the textbox on a form should always be the *same as the name of the table field* it''s bound to. And because the table field name should remain independent of its data type there''s no need to use txt, dtm, int or any other prefix.

sound about right?

>使用ControlSource中不同名称的意思是你可以

> The point of using a different Name from the ControlSource is that you can

然后轻松区分表格上的控件和
中的字段RecordSource。例如，控件具有Visible属性，但
字段不具有。关键方面是保持一致：如果为Field指定一个新的
值（命名与控件不同），在保存记录之前，您可能无法在控件中看到新的
值（at哪一点访问
更新控件）。

then easily distinguish between the Control on the Form and the Field in its RecordSource. For example, the control has a Visible property, but the Field does not. The crucial aspect is to be consistent: if you assign a new value to the Field (named differently than the control), you may not see the new
value in the control until the record is saved (at which point Access
updates the control).

正是我正在寻找的洞察力 - 现在我想我知道为什么我不得不

在某些情况下使用DoCmd.RunCommand acCmdSaveRecord。


谢谢。

Exactly the insight I was looking for - now I think I know why I had to
resort to DoCmd.RunCommand acCmdSaveRecord in some cases.

Thanks.

>似乎没有多少人在表级使用字段名称的前缀。

> Not many people seem to use prefixes for field names at the table level.

虽然有一些观点：当你在SQL中嵌入文字时，文本和日期/时间字段需要
分隔符字符串，当构建窗体过滤器，OpenCport的WhereCondtions，DLookup（）等的第3个文件时，会出现这种情况。

There is some point to it though: Text and Date/Time fields require
delimiters when you embed literals in a SQL string, and this crops up when
building filters for forms, WhereCondtions for OpenReport, the 3rd agument
for DLookup(), etc.

一个有点相关的问题 -


我理解日期/时间字段在SQL

字符串中使用时需要分隔符。但是当表字段被格式化为General

Date时会发生什么。 （其中字段包含时间），我将一个文字嵌入一个SQL

字符串，如＃5/17/04＃ - 这会导致问题，因为没有时间
$ b文字中的$ b？


一般来说，格式化表格字段是否更好，或者只是将表格

格式正确空白？我已经将表单中的许多文本框格式化为

日期/时间 - 文本框的格式是否与表格的格式相匹配？确定

重要吗？


再次感谢...

A somewhat related question -

I understand that Date/Time fields require delimiters when used in an SQL
string. But what happens when the table field is formatted as "General
Date" (where the field includes the time), and I embed a literal in an SQL
string like #5/17/04# - will this cause problems because there is no time
in the literal?

In general, is it better to format table fields, or simply leave the table
format properly blank? I''ve formatted many of the textboxes in my forms as
date/time - should the format of the textbox match that of the table? does
it matter?

thanks again...

这篇关于命名惯例澄清的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！