control names in Microsoft examples

[Guest]

Everything I have learnt from this forum about control and object names
emphasises the importance of prefix conventions like txt for text box, frm
for form, etc.
The value of this becomes very clear when you try to learn from the training
material on the Microsoft site or from the Access templates Microsoft
provides, where it's often impossible to figure out whether an expression or
a piece of code contains a control name or a field name. (Like when you try
to adapt one of the Access templates.) Microsoft training and help seems to
assume that control names will be identical with field names.
Obviously I'm not the first person to notice this, but I wondered if there's
some big, obvious principle I'm overlooking. Do Microsoft people secretly
follow naming conventions when they design Access dbases for themselves? Or
do they have some special way of immediately knowing whether, say,
"ProjectID" is the name of a control or of the field it is based on?

 

[John W. Vinson]

I wondered if there's
some big, obvious principle I'm overlooking. Do Microsoft people secretly
follow naming conventions when they design Access dbases for themselves?

I'm not sure that they do. Some of the sample databases - Northwind
amongst them - use structures that I don't like very much! I haven't
delved into "inside the campus" Access databases, and I'm sure they
vary substantially; but a lot of the training material seems to be
somewhat naive and divorced from real-world experience.

John W. Vinson [MVP]

 

[Guest]

In addition to John's remarks, My perception is Microsoft does not promote
good coding practices very well. One wonders what the code inside their
products look like. The also promote some bad habits that causes confusion
withing the community. For example, you will see MS Access Documentation
that refers to controls as fields. This drives me crazy. Fields are
properties of Tables and Queries. Form's do not have fields.

Proper terminology, Good Naming conventions, and verbose code comments are
very important.

 

[Jeff Boyce]

AMEN!

Jeff Boyce
Microsoft Office/Access MVP

In addition to John's remarks, My perception is Microsoft does not promote
good coding practices very well. One wonders what the code inside their
products look like. The also promote some bad habits that causes
confusion
withing the community. For example, you will see MS Access Documentation
that refers to controls as fields. This drives me crazy. Fields are
properties of Tables and Queries. Form's do not have fields.

Proper terminology, Good Naming conventions, and verbose code comments are
very important.

 

[Guest]

I suppose I was really looking for moral support here. I got it, and thanks
to all of you for telling me what I suspected.
My exasperation arose from trying to tweak one of the Access templates
downloaded from the web, specifically the Issues database which I downloaded
from
http://office.microsoft.com/en-gb/templates/TC012186931033.aspx?CategoryID=CT101426031033.
But in fact the Microsoft Muddle is worse than I first noticed. In this
particular template database, about half the controls are named using naming
convention prefixes and the rest are simply left the same as the field names.
If a student turned in work like this for a course assignment what sort of
marks do you reckon he/she would earn?
This one looked as if it would exactly suit the task I wanted it for and I
thought it would be a great timesaver, but I seems to me quite wierdly
constructed: lots of macros and almost no code, and with only two of its six
tables related to each other.
Would someone at Microsoft actually be doing work like this?