[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
>