Which way do you DIM your variables?

[Gasman]

Just seen a post on another site, where Dims are buried in an if block way down in the code. Saying that some are not even used even after being set.

I have always DIMmed mine at the top of a sub/function.

Sometimes they might not get used, if they are set inside an if block like this member has done (not sure it his code TBH though)
Now some people will say that is inefficient as you are declaring variables that might not get used?

I prefer to have them all in one place, so I can easily see if I forgot one, or need to change it's type for some reason, rather than have to hunt them down in all the code.
Might be a hangover from my COBOL days, but how do you Access professionals approach this?

 

[MajP]

There is an existing thread here too.

Premature Declaration

A topic most men tend to avoid...wait, wrong topic! Anyways, not a bad read. If you have about 20min to spare to read both articles, grab a cup of coffee and have a read... https://nolongerset.com/premature-declaration-redux/

www.access-programmers.co.uk

 

[Gasman]

Such is my memory.

User in question has proved point 4 incorrect from that link

4. Avoids Unused Variables: By declaring variables close to where they're used, it's easier to avoid declaring variables that never get used or are only used far removed from their declaration point. This can also help in identifying and removing obsolete variables during code reviews or refactoring sessions.

 

[Uncle Gizmo]

I occasionally use both, but predominantly put the variables at the top.

Why?
It's the "unused variable" issue.... If the variables are at the top, then it is easy to select the variable and run a find and replace to see where that variable is used throughout your module. If there are no other instances of it in your code, you can safely delete it....

 

[MajP]

4. Avoids Unused Variables: By declaring variables close to where they're used, it's easier to avoid declaring variables that never get used or are only used far removed from their declaration point. This can also help in identifying and removing obsolete variables during code reviews or refactoring sessions.

Not much of an issue now a days for anyone writing much code. Since you are likely to have a code writing utility like MZTools which will show all dead code.

 

[The_Doc_Man]

I have to admit I'm old enough to have been taught programming in languages that were stricter in structure; strict enough that in-line declaration was not allowed. For me it is habitual and ingrained to declare everything up-front. Modern versions of compilers "learned" from their earlier cousins by building code and building data in two different program "sections" and later butting one against the other to form a unified whole only when the last line of code has been compiled.

Nowadays, when you talk about compilers with "data execution protection" and "non-overwriteable code", they employ hardware memory management methods to make those sections have different execution properties. I first met THAT trick on the VAX computers built in the 1980s by Digital Equipment Corp. - sadly, now defunct. Some of their products live on because HP bought out COMPAQ which in turn had bought DEC. Since the compiler builds the sections differently now, the location of a declaration is less of a technical issue. It remains an issue of style.

 

[Pat Hartman]

Might be a hangover from my COBOL days, but how do you Access professionals approach this?

I have the same hangover. Old habits die hard. COBOL also required declarations but VBA does not which I think is HUGE problem rather than an asset. COBOL was a three pass compiler. That meant that it had to process the source three times to complete the compilation. Then the compiled code was processed by the linkage editor to connect it to called procedures that existed in stand alone modules. Think of DLL's. Programs with embedded SQL code required a pre-compile step to handle creating all the queries. I can't remember the details of each compile step. It was a long time ago. BUT VBA is an interpreted language and that implies a ONE pass model. The source code is converted to something called p-code as the source is saved. ALWAYS compile and save before testing. Never leave uncompiled code and save it. That is just plain sloppy. Then when you run the code, it is the p-code that is being executed. This is why it is dangerous to be changing your code while it is running. Access has to sync the source you are editing with the p-code it is executing. I am guilty, I confess but I do know the danger and I do save and compile immediately which minimizes the risk but does not eliminate it.

Anyway, the question that leaves me with is, if the variable is defined 30 lines into the procedure and you add code in front of it, does the code still work? I suppose I could create some and test it but those of you who embed your Dim's in line should know the answer.

Given that I understand coupling and cohesion, very few of my procedures have more than a handful of variables anyway so declaring them all together at the beginning doesn't separate them that far from where they are used. I've made changes to code written by others who declared the variables as they used them (I was ecstatic that they bothered to declare their variables at all) and for me,finding a variable was actually more difficult because I had to keep reading code to find them because I was never sure where the "first" reference might be. So, when it is your own code, and you still remember it, then you don't have any trouble finding the definition if you need to see it but if it is someone else's code or you wrote it 5 years ago, it may be easier if all the Dim's are together at the top of the procedure.

 

[The_Doc_Man]

Anyway, the question that leaves me with is, if the variable is defined 30 lines into the procedure and you add code in front of it, does the code still work?

Since for Access we ONLY write subroutine/function code that places its local context on the stack, I think it doesn't matters how you DIM things - at least, not mechanically. If you think of it as a parallel allocation, the compiler looks at something and knows, for variables, to add a slot in the growing "stack context" area. It also knows how much code exists but THAT doesn't go on the stack.

When the compiler reaches END SUB or END FUNCTION at that point it knows how much space to put on the stack as a context area because by then, all of the DIM statements (and any variables created by not having set OPTION EXPLICIT) have been identified. When you actually activate your routine (SUB/FUNCT), all that Access does is allocate and erase a context area on the call stack before it enters your code sequence. (I've been reading the VBA Language standards document.)

Any local variable ceases to exist when the code reaches an END (SUB/FUNCT) or the EXIT (SUB/FUNCT) - which implies the END statement - of the SUB/FUNCT that declared it. This erasure occurs by simply resetting the stack pointer to the context of that routine's caller. Technically, some of the values are still in the stack area for a little while, but could only be accessed by assembly-level code.

The only exception is a STATIC variable, which gets stored in the declaration area for the module in question. The lifetime of a STATIC variable is for the duration of the module containing the SUB/FUNCT that declared it. So for class modules, STATIC goes away when the class module's associated object closes. For general modules, STATIC resides among the PUBLIC variables but isn't PUBLIC. And it goes away only when the code is RESET or when the app exits and drags the general modules away with it.

 

[Gasman]

Easy to test I expect?

 

[gemma-the-husky]

I prefer to keep my variables together for ease of reference, so the top for me. I actually often put the variables into a typed structure so I get some intellisense when referring to them, especially if they are connected logically.