|Do you know where your variables are?|
Re: I present to you... Horrible code!by cchampion (Curate)
|on Jan 08, 2005 at 09:29 UTC||Need Help??|
Not golfing, because you won't get decent code from golfing horrible code.
I'd rather see this code as a spot-the-mistakes execise.
Thus, here come my changes:
However, the first blunder, the one that eventually led to the current horrible code, is that there are four database tables instead of one.
Thus the first order of business would be to merge those four tables into one, adding a "quarter" column.
With that in mind, you could rewrite the above function as follows:
That said, this function, in its original form, is completely useless, because it is executing a SELECT request from a locally scoped statement handler, and its result would be simply lost. A returning statement for such a handler is needed, if you want to pursue any practical purpose.
What else? Ah, yes, the global @userdata array, of which we have just to assume it exists and has valid data in it. It should be passed as an argument as well.
FInally, that naked numeric literal "2" used as an argument to "execute" and "error" should be turned into a variable, so that whoever has to maintain the code knows what it is about.