Darryl Collins
darryl at whittleconsulting.com.au
Mon Jul 1 22:15:37 CDT 2013
In addition to being older, you are also smarter. Why on earth would you want to go to the bother of doing the hover or click when you can just 'know' by looking? Those young punks still have a lot to learn. I occasionally dim field names the same way. Whilst I agree it could be bothersome to update them all, I don't really have that issue thanks to many years of use with Rick Fischers "Find and Replace" for Access. Which still works great in A2010 I might add. In my current role I can afford to be less 'proper' as the team I work with are all pretty good with VBA and Access and we use all our tools in house only. That said, the more specific you can be, the easier debugging generally is. Sloppy code or dimming usually bites you sooner or later. Cheers Darryl. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of David McAfee Sent: Tuesday, 2 July 2013 2:19 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] VBA Field Names - Curiosity Question 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