Is this causing a problem? I'm not sure what the concern is.
This is actually a pretty standard tactic that I use even in my manually created scripts. Let's say, during the course of writing a test, I open a Form... I assign that form to a variable so I can go back and reference that form later... then I open a child form... well, I want to preserve my first form so I create a new variable and assign it... I close that child form... and I can now use my first variable to reference the form from earlier. I open a different child form... well, the first child form is "gone" so I can reuse the variable
...and so on.
The idea is that you assign an object to a variable for two reasons. First, to make it easier to reference it ( a lot easier to say "Button1.ClickButton" than "Sys.Myapp.MyForm1.MyForm2.MyForm3.Button1.ClickButton") and secondly to be able to refer back to the object later in the same script. So, if the object technically still exists in memory, you want to keep that variable around so you'll need to create a different variable. But once the object goes away, you can then reuse the variable.
We tried, at one point, to use the same variable (w) for all forms and windows... and it ended up confusing things because it was hard to tell which form was being referenced by the w.
Now, another thing to note... when you have that many variables defined in the beginning of your code, is it possible that your test is doing too much? Are there tasks, workflows, procedures, etc., that may be able to be broken out into other functions? Especially tasks and such that may be re-useable across a number of tests. For example, logging in to your application. Can that be pulled out to a seperate function? That would reduce the number of variables in test as well.
So...it's just a matter of technique, need, etc.
