Charlotte Foust
charlotte.foust at gmail.com
Mon Jul 1 11:17:13 CDT 2013
Don't blame Hungarian notation for that. It was someone else's idea to apply it to fields. That never made sense to me because of the labor involved in *renaming* a field if the datatype has to be changed and then propagating that to everywhere the field is referenced (Note: I do NOT use Name Autocorrect, which doesn't work in VBA code anyhow). On the other hand, I've always used the Lezynski-Reddick naming convention. Charlotte On Mon, Jul 1, 2013 at 8:48 AM, Steve Goodhall <steve at goodhall.info> wrote: > It's not just a VBA thing. Blame it on Charles Simonyi, hence the > Hungarian Notation. See en.wikipedia.org/wiki/**Hungarian_notation<http://en.wikipedia.org/wiki/Hungarian_notation> > .! > > Steve Goodhall > > -----Original message----- > From: John W Colby <jwcolby at gmail.com> > To: Access Developers discussion and problem solving < > accessd at databaseadvisors.com> > Sent: Mon, Jul 1, 2013 15:32:13 GMT+00:00 > Subject: Re: [AccessD] VBA Field Names - Curiosity Question > > I think the practice started simply because the dim statement can be in > many different locations inVBA. It can be in a global module (global to > all modules) , or it can be in the header of themodule (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 tomanipulate 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 itis 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<http://databaseadvisors.com/mailman/listinfo/accessd> > Website: http://www.databaseadvisors.**com<http://www.databaseadvisors.com> > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/**mailman/listinfo/accessd<http://databaseadvisors.com/mailman/listinfo/accessd> > Website: http://www.databaseadvisors.**com<http://www.databaseadvisors.com> >