Continuing from yesterday’s Global Domination theme today I worked on finalising my global annihilation. I worked on getting rid of almost all of the globals in the path way that I’m working on at the moment and I feel that I’ve succeeded. The application is perhaps a textbook example of why globals are evil.

Today I got a handle on the extensive amount of variables. Whilst yesterday I managed to get the configuration global variables wrangled in and put into a nice neat little class and out of the global scope which made a whole heap of things clearer.

The piece of code in question is a data mapping system. It takes an array as an input and then transform it eventually into XML and feeds this into a web service. The list of valid keys is stored in an array (in the global scope) which is filled in with the values from the input array. I couldn’t work out why there was a function that basically appeared to clear what was an empty array until I realised that the global was being filled with data and so if the code path was reused it’d have the old data in it. Nasty work around for a problem that should have existed.

So the functions related to the mapping and the two arrays that were living in global scope were shifted into a class on their own. The relevant functions were adapted to work properly with the variables not being global and I’ll work on eradicating the other situations where the variable was still used but the particular purpose I need it for is cleaned out. At the same time I pulled into the class some extra functions that were related to the system but weren’t located with it (curiously enough!).

But working through the mapping functions I noticed another quirk. Just as previously the global was being altered even though it was supposedly a template, another one of the functions decided that it would alter the input array that it was given before setting that value in the output array. The field in question, a format field, is reset if the field isn’t set under a particular condition in a loop. This means that the loop goes through a few times and this variable is undefined and the items checking this behave one way. Then an iteration occurs which triggers this code path and the variable is changed. The lines that were previously run would have checked that and possibly taken a different code path as would the following items. Why this approach was taken baffles me and could potentially be a source of a few bugs. It is unlikely this has been a concern as the code spewed out copious amounts of undefined index errors due to insufficient checking to see if the values were there and just hoping they would be there. Fortunately I managed to clean up the majority of it though a few undefined index errors remained. The solution mostly was using Joomla!’s JArrayHelper::getValue function which will work out if the value is set and give you the option to filter the value to a particular type and also set a default value if one isn’t there. Handy little function cleaned up the majority of the errors.

A few other changes were made, globals were annihilated and I progressively removed dependencies to clean up the system and all was right with the world. And tomorrow? Fix another part of the broken.