[AccessD] VBA Field Names - Curiosity Question

That I am not sure of, but the younger developers love to name
objects/variables stuff like "Name", "Date" because that's how Microsoft
does it.


On Mon, Jul 1, 2013 at 9:26 AM, Charlotte Foust
<charlotte.foust at gmail.com>wrote:

> Does that mean you can now have a query and a table of the same name??
>
> Charlotte
>
> On Mon, Jul 1, 2013 at 9:18 AM, David McAfee <davidmcafee at gmail.com>
> wrote:
>
> > I still prefer to use Hungarian prefixes for variable names (and tbl, vw,
> > stp... for table, view and sproc names).
> >
> > My younger coworkers love the new way of "not" doing that.
> > They explain how you can click or hover on a variable too see what it is.
> >
> > I love not needing to. just looking at it tells me what it is.
> >
> > I guess I'm just getting old.
> >
> >
> >
> > D
> >
> >
> > On Mon, Jul 1, 2013 at 9:11 AM, Jim Dettman <jimdettman at verizon.net>
> > wrote:
> >
> > >
> > >  To add to that, right click/define didn't exist in Access Basic
> either,
> > so
> > > it was a real hunt back then to find where (and how) you declared a
> > > variable.
> > >
> > > Jim.
> > >
> > > -----Original Message-----
> > > From: accessd-bounces at databaseadvisors.com
> > > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of John W
> Colby
> > > Sent: Monday, July 01, 2013 11:31 AM
> > > To: Access Developers discussion and problem solving
> > > Subject: Re: [AccessD] VBA Field Names - Curiosity Question
> > >
> > > I think the practice started simply because the dim statement can be in
> > > many
> > > different locations in
> > > VBA.  It can be in a global module (global to all modules) , or it can
> be
> > > in
> > > the header of the
> > > module (global to the module) that it is used in or it can be in the
> > > function where it is used
> > > (local to the function).  It is useful to know what datatype something
> is
> > > when you are trying to
> > > manipulate it.  Multiplying a string with an int is going to cause
> > > problems.
> > >
> > > OTOH, strMyVar * intMyOtherVar makes it immediately obvious that we
> don't
> > > want to do that.
> > > Instr(intMyOtherVar...) is immediately obvious.  Many issues will
> compile
> > > but give run time errors.
> > > Corner cases that only run once a year can cause nightmares to resolve.
> > >
> > > Just because language practices 40 years ago doesn't do something
> doesn't
> > > necessarily mean that it
> > > is bad idea.
> > >
> > > John W. Colby
> > >
> > > Reality is what refuses to go away
> > > when you do not believe in it
> > >
> > > On 7/1/2013 11:01 AM, Brad Marks wrote:
> > > > All,
> > > >
> > > > In a prior life, I was sentenced to work with COBOL for over 30
> years.
> > > > For the past three years, I spend my time in the world of VBA.
> > > >
> > > > Since starting to work with VBA, I have been curious about something,
> > > > but have never asked about it.
> > > >
> > > > In the COBOL realm (at least where I worked), we did not indicate the
> > > > field type in the field name.
> > > >
> > > > Examples -
> > > > 01 Part-Number   PICTURE X(30).
> > > > 01 Part-Cost    Comp-3    PICTURE 9(05).
> > > >
> > > >
> > > > In VBA examples, I see most people using prefixes such as Str, Lng,
> > Dat,
> > > > Etc.
> > > >
> > > > I have never quite understood why people do this when working with
> VBA
> > > > while I believe that very few people did this in the COBOL realm.
> > > >
> > > > In COBOL we would simply look at the Picture clause in the field name
> > > > definition.  This would be the equivalent of looking at the DIM
> > > > statement.
> > > >
> > > > Again, this is just a curiosity question.
> > > >
> > > > Thanks,
> > > > Brad
> > > >
> > >
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> > > --
> > > AccessD mailing list
> > > AccessD at databaseadvisors.com
> > > http://databaseadvisors.com/mailman/listinfo/accessd
> > > Website: http://www.databaseadvisors.com
> > >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>