# Organize Project Variables: Hierarchy?
**URL:** https://www.finalbuilder.com/forums/t/organize-project-variables-hierarchy/3859
**Category:** Feature Requests
**Created:** [May 28, 2007, 7:54am UTC](https://www.finalbuilder.com/forums/t/organize-project-variables-hierarchy/3859 "2007-05-28T07:54:28Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@miracle2k](https://www.finalbuilder.com/forums/u/miracle2k)
#### Post date: [May 28, 2007, 7:54am UTC](https://www.finalbuilder.com/forums/t/organize-project-variables-hierarchy/3859/1 "2007-05-28T07:54:28Z")
I mentioned in a previos thread ([https://www.finalbuilder.com/forums.aspx?forumid=1&postid=3053&view=topic](https://www.finalbuilder.com/forums.aspx?forumid=1&postid=3053&view=topic)) that I wasn’t quite satisfied with having a large number of variables defined globally, although they may only be used in some sub-sub-action group of an action list.
Recently I had an idea that could maybe mitigate this a bit without requiring a huge rework of internal mechanics. Let the user organize the variables in a tree structure. That way, I could have:
Script option variable
|—Var1
|—Var2
Foo List variables
|—Var1
|—Var3
Temporary Loop variables
|—i
|—j
|—string\_value
Just an idea, not sure how feasible it actually is 😉
Michael
---
### Author:  [@stevage](https://www.finalbuilder.com/forums/u/stevage)
#### Post date: [May 29, 2007, 3:37am UTC](https://www.finalbuilder.com/forums/t/organize-project-variables-hierarchy/3859/2 "2007-05-29T03:37:33Z")
I agree that some more organisation would be very helpful. One of my projects has 50+ variables, and it’s pretty hard to keep track of them all.
A couple of ideas:
1) Allow iterators to have implicit variables. That is, a loop iterator would automatically define a variable called %loop1% which is only accessible from within the loop. A sub-loop would call its variable %loop2%…
2) Fix the problems with action list parameters, making it really possible to use parameters as local variables.
3) Groups as Michael suggested. I tend to use naming conventions (“Toolxxx” means a path to an external 3rd party program, “Buildxxx” means a property of the build as a whole…) but groups would be stronger.
4) Implement cascading variable renames, to make it easier to rename variables when needed. It’s just too risky atm, and much safer to leave a badly named variable the way it is.
5) Improve the Watches tab. In particular, buttons for “watch all” and “clear all watches”.
6) Amalgamate the different variable windows: add variable, variables editor, watches, modify variable. None of those places has all the necessary functions: change default value, change current value, change flags, rename, reset to default value.
Steve