@brianmcculloh said:
No, that was my first post. Did I do something wrong?
I think he is confused because we have the same last name. Probably thought I forgot my password or something and reregistered as "brianmcculloh"...
@brianmcculloh said:
No, that was my first post. Did I do something wrong?
I think he is confused because we have the same last name. Probably thought I forgot my password or something and reregistered as "brianmcculloh"...
@bstorer said:
@cmcculloh said:(etc, etc, up to 500 zips) and therefor in some cases encompasing the entire universe.I was unaware we had assigned ZIP codes to the entire universe. Is that what the four-digit extension is for?
Yeah, but no, there's actually an extra nine-digit extension you can use for intergalactic zips. It only works for the milky way though, after that they start using greek lettering preceeding the zip...
I'm working with some pretty attrocious code. Every line contains at least one wtf. I've become kind of numb to them by now. But this one was a perfect argument for coding correctly, and not coming up with "clever tricks". You should never have to "trick" the computer into doing what you want. Coding should be intentional, not magical.
So anyways, I'm working with a script that takes a radius and inserts all of the zip codes within that radius into a database. The new radius is passed through the header as "inputFD[2]", instead of "newRadius" (or something logical like that). Well, the same page (consisting of 10 different files ranging from 300-1200 lines of mostly uncommented code) used in a different context, unbeknownst to me, also passes a list of zipcodes to be inserted into a different DB table through, you guessed it, a header variable called "inputFD[2]" instead of something logical like "zipList".
Shortly after testing (quickly) and launching an update to this page we started getting jobs that would be assigned every zipcode in the entire USA. We were confused at first. I wrote the code that did the assignment, but I had very little knowledge of the insane spaghetti code that I was inserting this code into. I assumed that inputFD[2] was only ever a zipcode radius, and also assumed that the place I was putting the code to do the insert was only ever run when they were actually working with zipcode radii. These are the sort of assumption one has to make when your boss wants something done NOW.
By now you may have realized what happened. There is another view of the page that I had no knowledge of where the user can enter a list of zips and it will be passed through the inputFD[2] variable and parsed by my script as if it were a radius, resulting in the script thinking the job has a radius of "27943,23817,23481,23492,..."(etc, etc, up to 500 zips) and therefor in some cases encompasing the entire universe.
sigh.
Please give your variables a clear name and one purpose. PLEASE.
Oh, and this is the from the same PHP page that was the topic of this post. I could probably fine 100 other gems like this in the code in that page...
@shadowman said:
Was that supposed to be more like:
<font face="Lucida Console" size="2"> for ($i = 0; $i < count($control->BLACK_VARS); $i++) {
</font>$control->BLACK_VARS[$i] = $hidden->BLACK_VARS[$i]; }
???
No, see, that would actually make sense. This code actually presumably works as intended, and would be considered "correct" by it's author (and, yeah, the page actually works correctly). I have no freaking clue what this code does yet, but I'm sure I'll figure it out. $BLACK_VARS is an array that I'm sure I will find buried within some included file somewhere. This sort of thing is exactly what led me to find this code block in the first place. I had another array that was being used in this sort of way in another file to call a function that used a variable set by a function called by the $control object, that was being used by another file included in this base file, which I'm sure will in turn lead me to whatever file this BLACK_VARS array crawled out of (hope that made sense). It's a mess. I'll post when I know what is actually going on...
Yeah, it's PHP.
No typos, I copied and pasted that code.
What I've found is that this is how they like to call functions, set properties, etc. For instance, they will submit a form that sends a "function call" like so:
URL something like:
somePage.php?runs=1&mops=34&stns=free
Code at URL is something like:
$KOWR = array("GENERAL", "REPORTS", "GEO", "ZIPSGET");
$body = $KOWR[$runs]($mops, $stns);
//snip 100 lines of html echoed out
echo " <td><center>" . $body . "</center></td>";
Then the code in some random included by an included include file is something like:
//at about line 1500:
function REPORTS($mops, $tetras){
//snip about 100 lines of HTML concatinated line by freaking line with nested upon nested un-indented if statements
return $body;
}
And none of it is really comented at all. Well, it is, but it doesn't really mean anything to me. Comments pretty much go like:
//for pre-defined, we need to take what is in the hidden element rather than the control -- control is used to update with pKeys (function updateFields)
Which is guess is marginally better than nothing... (note that the above comment immediately preceeded the "BLACK_VARS" if check)
For the first time since starting my job six months ago I found myself literally banging my head against the desk.
After wading through uncommented spaghetti code for over an hour I finally came on this line, which was the proverbial straw:
for ($i = 0; $i < count($BLACK_VARS); $i++) {
$control->$BLACK_VARS[$i] = $hidden->$BLACK_VARS[$i];
}
The "control" object has no such property (nor does the hidden object), and in the file I'm working with these are the only references to this mysterious array.
The name ($BLACK_VARS) kind of sums up how I feel the previous developer must have felt about most of their programming. It all was just sort of "black magic", copy this here, do that thing there, hold your tongue just right and cross your fingers, say the magic words, and maybe, just maybe, it'll all somehow work...