I also agree with Phillip, sounds like he has a good system. With pointers, you just have to keep in mind that all the pointer names are part of the naming convention and are the names of actual devices and inputs or outputs in the field. Like Phillip said, you initialize all the variables in a init block prior to the loop, then load all the pointers from the pointer table at the top of each loop right after increment of the index value. For instance, the pointer Pump_Run_ptr would be a pointer that is loaded in the pointer table in the init block, then after Pointer_Index value inside the loop is incremented to 1, then you would load the pointer table with Pump_Run1 var and then beyond that in that loop, you can do anything needed with regards to starting or stopping that pump. This goes for essentially any var type in Pac.
I also agree with Phillip on the Excel trick. Been using that one for many years. Essentially, anywhere you have to load pointer tables with vars, you create the script itself in Excel and the copy and paste into a script block. When you paste a 100 lines of script into the block, you'll have that feeling of euphoria....
As far as your project, it might be wise to have one person be the naming convention guru and that person would keep the master list. I know the Opto way for naming is to put the data type first, but I never found that to be as helpful as listing the device first, such as Pump1_Run. The point of this is when using pointers, you might have hundreds of vars, and this will group all these items together when you are working on the strategy. Another thing I do is use a post fix such as Pump1_Run_do for all my discreet outputs, then use Pump1_Run_dout for my internal variables. Pump1_On_di and Pump1_On_din likewise. This lets me know whether I'm looking at a variable or an IO. Of course you can tell the type typically by what it's doing. Another set of examples is Pump1_Press_ai/Pump1_Press_ain and, Pump1_Speed_ao/Pump1_Speed_aout. This way, when you type in Pump1, the tree will take you right to the group you're interested in working on and you can look at this list and see if mistaken names are present, etc..
Using tables like Phillip said is really really compact, but it comes at the price of complexity. I typically use individual like named vars for each IO which makes troubleshooting easier. Also, I almost always use the block read method for reading and writing the IO, for that I use tables and for which the Excel trick is paramount.
I suggest sitting down with your team and working out all the device names and associated variables and IO, or least the most obvious ones. Keep in mind how you're going to be using them and that will do more to keep your strategy on a sane path.
I have a fairly good size project coming up next month and I will be putting all these things in play, which will be especially interesting since I will be using the integrated redundancy kit and 2 Groov servers (intended as redundancy) to operate 20 - 50hp fans and all the associated alarms, and safety systems. There are hundreds of IO, 2 controllers and 13 brains, 2 server PCs, 2 operator PCs with 65" UltraHD displays, and a dozen other monitor PCs on this system.