For example, I have three arrays that each have to be spliced whenever one of them is, but that's not obvious when working on a routine that deals with only one of them

Use objects. Really. Your problem is that you are doing something complex and scurrying around doing all the things a good object system should be making simple manually all over the place. And as you have discovered, as a system grows large, it becomes impossible to keep all the details in your head at one time.

Step back from your code and analyze what it does. Massive use of global variables is usually a symptom of lack of analysis - you didn't know what you were going to do before you did it. In the hundreds of packages totaling megabytes of Perl code I've written in the last few years, there are only a few _dozen_ global variables - nearly all of which are in fact constants.

If you have three things that have to be maintained in complete synchronization - embed them in a 'container' object that understands how to update and read them. Talk to the container object - never directly to the hashes. Then updates only take one simple call and you worry about what not how the container does what it does in the rest of your code.

What? The whole idea of a properly modularized program is that you don't have as many interdependencies among variables or among different parts of the code.

What needs to be done, and which can be done without objects if desired, is to have the program separated by some opaque barriers and to group truly structured information into real data structures.

There seems to be three ways I could handle this.

• When I have to change a variable, check everything else that might require that variable to be changed and make all the changes in a relatively confined area. Only one comment on the use of the variable would be needed.
• Use subroutines for major divisions of the script and when they would make the script shorter, with comments to avoid problems with variable interdependencies. This is what I'm doing.
• Use subroutines or objects to avoid problems with variable interdependencies, in addition to subroutines for the major, parent divisions. This is what people are suggesting.

In my case, using comments rather than subroutines or objects for my array triplet (actually, I just realized it's a quadruplet) avoids problems with variable interdependencies just as well. It also makes my code easier to follow and understand, run faster, and easier to develop (especially for me).

Yesterday, I forgot which of those arrays had been added to by a certain point in the script, and I wanted to splice those that were added to. Rather than permanently using a splicing routine that checks the length of the arrays, I used such a routine as a debugging tool only, found out which arrays had been added to by that point, then permanently added lines to splice only the arrays that would need splicing at that point. In addition to preventing having to dig deeper into the code to understand it, my unconditional splicing makes apparent which arrays had been assigned to by that point in the code, which could be useful for future maintenance.

If it makes it easier for you, then that's a good thing. I'm having a hard time understanding how having four arrays which are closely related is better than having a hash of four arrays.

Of course, without actually seeing an example of what your code is doing, I can only respomd in the most general of terms. I may not even be really clear on just what you do have. The way I understand things from your descriptions, though, there would be many things I would do that would make it easier for my own understanding if I were doing the coding. You and I may just think in different ways.



Christopher E. Stith