When you have that many items located in a form, it is best to use an array instead of separate variables.
I like to think of think of this as "packaging" the data into an easy to read data type. Use an array instead of separate variables for every item.
Ask yourself. What is easier to manage? ONE variable or HUNDREDS?
Here's an example. Let's say you create a form that is part of the installation of your application. In the installation program, there is a form that prompts the administrator for pieces of info for setup:
$gSetup["Admin"]["First"] = "Joe";
$gSetup["Admin"]["Last"] = "Smith";
$gSetup["Contact"]["Email"] = "joesmith@yahoo.com";
$gSetup["Contact"]["Phone"] = "(123) 456-7890";
$gSetup["Address"]["City"] = "San Jose";
$gSetup["Address"]["State"] = "California";
$gInfo["Address"]["Zipcode"] = "12345";
Here, $gSetup is a multidimensional array that takes string keys as its indices. You can clearly see how the data is catagorized and packaged. The category is the first index (like Admin, Contact, Addres) and the property of each category is in the second index (First, Last, Email City, etc.).
You can appreciate the above if you have worked on large coding projects on a team of engineers where every engineer writes code differently. By enforcing a coding style and set of rules, you make it easier on others, as well as yourself.
Let's say, this information is to be used throughout a large project, say of 1000 PHP files and some 100,000 lines of PHP code. Unless you are very disciplined about how you name your hundred of seperate variables and have a keen memory of their purpose by looking at the name of the variable only, you are setting yourself up for a lot of error prone work.
Doing this:
$first = "Joe";
$last = "Smith";
$email = "joesmith@yahoo.com";
$phone = "(123) 456-7890";
.
.
(hundreds of other variables)
is not a smart thing to do.
The problem is that in a large project of many files and many lines of code, knowing WHERE each of these hundreds of variables are CREATED, SET, CLEARED, DELETED is like finding a needle in a haystack.
The benefits of packaging your data results in code that reads easier semantically, has less chance of name collision, and offers faster debugging.
You maintain the relationship between data items. It gives you a clue of where the data came from (its the setup code, it originated from the setup form, etc.).