John W Colby
jwcolby at gmail.com
Mon Jul 1 11:25:54 CDT 2013
As do I. VBA (an other office) editor doesn't have that stuff and I still work in that so I still use Hungarian notation. I even do so in C# which has the hover stuff. If you are just reading the code on the page, without a notation it isn't obvious what it is. I do understand the argument that "everything is a class these days" and that "there are thousands of classes" which definitely makes Hungarian notation less useful but still not useless. And there is no need to guess, I am definitely getting old. ;) John W. Colby Reality is what refuses to go away when you do not believe in it On 7/1/2013 12:18 PM, David McAfee 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 >>