That’s how the original programmer formatted it. Almost every mistake imaginable is in there. While I fix the thing I’ve posted the original for everyone to point and laugh.
If it takes you more than a minute to fix a file like that, I would be much more worried about your coding than your colleagues. And I’ve seen much worse.
IMO, not formatted codding is also itself a bug even if there is no syntactical error for PHP interpreter. I really get frustrated when i see such codes. I always copy, paste in my IDE and format the code before seeing for the mistakes in this forum posts. I really dont like the script coded like above. To make the habit, try to use some PHP compatible IDEs so that it makes one’s life easier to format the code.
Right, because the computer can sort out the procedural bugs the crap coding harbors. You’re holy grail IDE approach that any idiot can take led you to glance right over the very real problems in this code that cannot be fixed by any autotab system.
So thanks for the insults and the display of gross ignorance and welcome to my killfile
I can feel you pain but at the same time top that BIG TIME.
I got into a project where I was just going to ‘redo the front end’ and then got drafted into working on the underlying code, to say I was shocked at what i found is an understatement.
Think about some of the worst naming conventions possible, add to that not one stinking comment and then just for fun ten tons of global variables (and the code was just written last fall) … not that bad right?
Well then add on top of that a programmer that was obviously an ex-Java programmer and thought the more objects you create the better. If you started at line one of his index.php file by the time you got to line 11 you literally had 40 files open, each one of them included or included in an include … seriously I kid you not.
Then to make it worse he decided creating instances of objects when you needed them was too much trouble so on line 12 he included an auto loader that literally ran through every folder in the site and loaded every object within them. At last count I figured he was loading something like 200+ objects on each page load. I tried to drop the whole application into xampp so I could figure it out and it literally shut the server down.
And just when you thought he couldn’t get any crazier ever bit of SQL was in prepared statements. Stuff like “SELECT COUNT(*) FROM table” was a stored procedure.
>>> That’s how the original programmer formatted it.
>>> Almost every mistake imaginable is in there.
>>> While I fix the thing I’ve posted the original for everyone to point and laugh.
Did the code work and was it written at five-o-clock on a Friady night?
No, it did not work. Floating point arithmetic is bad - converting floating points to strings before adding them only worsens the problem. Part of the conversion is changing all the values to integers before adding them to insure the reports are accurate down to the cent. (dividing by 100 at display time is trivial enough)
That can only explain so much. While I have been never met the guy who wrote the original block, during my tenure I’ve been told many, many stories about the bad personal behavior and interpersonal skills the guy had. Now admittedly I’ve heard only one side of the story, but I’ve come across evidence in the code itself.
For example, finding the guys test variables is easy - he uses select four letter vulgarities to test. Then he leaves them in the code and on one spot it was being echoed out to the screen.
There are no comments in the code base at all with the rare case of a // end foreach comment which of course gives me information that would have been obvious to both me and him if he’d indented properly.
Of the stories I’ve been told the most outlandish was the one about the testing of printing functionality. You see, unlike most PHP programs this one needs to address a printer directly which is connected to the server (we have one shared office printer that all the client machines and the server are pooled to). To create the claim forms the PHP postscript library is used.
When I got there the documents looked utterly terrible. Nothing was aligned - check X’s weren’t aligned to their boxes but most importantly much of the information was still flat out wrong. This after the guy had went through NINE CASES of paper, 2 printers, 5 toner cartridges and a shredding machine (the documents must be shredded after tests because they hold patient information).
That’s right - he printed every single test and after 6 months of work had still failed to get it right. The code block he had concocted had only one real use to me - it was a live example of the postscript functions I’d never used. Rather than rewrite his block I wrote a class to handle the output.
The very first thing I did though was find the line where the [fphp]system[/fphp] statement fired up the printer. During testing I commented out that line and wrote the 4 lines of code necessary to send the postscript file to the browser along with the correct headers - then went online to find and download a plugin for Acrobat to open and view the things.
I then wrote the functionality required in 3 days and used 5 sheets of paper for final tests. It’s very hard to respect a guy needing 6 months to do the same task while wasting around a couple hundred dollars in paper and still failing to get the project to work.
The worst part though is about the month after I started the guy went to a client of the company to brag how some of the errors in the software where put there intentionally. When I heard this I lost what little sympathy I had for the guy.
