Forums
Code Snippet Of the Day (CodeSOD) features interesting and usually incorrect code snippets taken from actual production code in a commercial and/or open source software projects.
As he popped the blister pack on another pair of 'industrial grade' antacid pills Brian recalled the contractor's first few weeks in the department.
Everything was better at his last assignment. The department's development processes were obsolete and the development tools he was given? Don't even start. His way, no matter how convoluted or obtuse was the best way. Don't question it - just get used to it.
"My company makes a device with a movable wheel that's connected to a computer," Geoff writes, "the device incorporates a design where notches in the wheel encode a binary pattern that can be read by sensors. The computer determines the position of the wheel by reading the sensors from a digital I/O card."
"It's actually a clever way of putting an impromptu encoder on the wheel. The software is, unfortunately, not so clever."
Jeff C. was hired as an exterminator. The "big rewrite" had a lot of "big bugs" that needed to be eliminated, which was somewhat ironic, as the big rewrite was commissioned to eliminate a lot of "little bugs" that found their way into the original system over the years.
A product of neglect and abuse, the original system had become a crazy nightmare of Classic ASP pages. Nothing fully worked, but things half-worked half the time. The big rewrite yielded exactly the same thing, but in VB.NET. There have been talks about rewriting the rewrite, but in the mean time, Jeff's day-to-day involves toiling in code like this:
"I was recently hired as an enterprise architect," Chris writes, "and my first task was to assess how far off the 'silo developed' applications were from the newly-implemented, company-wide standard."
"While I could submit a WTF for every hour I worked on this task, following is what I found in a lone WPF application containing a single screen with 1,890 lines of code.
It was another project at another place, and when Paul had settled in, he was given his first task. It was to get an application running after the original author had left. Apparently, it was "giving problems" when someone tried to get the code from the repository and build it. Paul dived into the code and started looking.
The code base was large. Very large. It was an imaging processing test application that gathered images from custom hardware and performed some fairly complex maths. What stood out though, was the idiosyncratic coding. Outside the number crunching, there was a slowly emerging pattern. Every function call took the following form.
"For some reason," writes Graeme Hefner, "someone decided that it'd be best that we write our own bug/issue tracking system instead of using one of the plethora of fully-functional systems available on the market."
"For some reason, someone — perhaps the same someone — decided that the best way to develop this system was a SQL stored procedure called by a Classic ASP page that simply dumped everything to a single page list. Every ticket, ever. This is the core of its entire logic, which impressively uses of SQL, HTML, and JavaScript all in one query."
Mike P had some rather large sandals to fill. His predecessor was a self-described "PHP God" who had, much to the chagrin of his followers, left to bestow his benevolence elsewhere. While mere "PHP mortals" might misunderstand his code to be convoluted and bizarre, those who knew better (i.e. management) sang plenty of praise, of both the PHP God, and his clean, well-commented code.
But the PHP God did much more than simple sites – he solved what many would consider unsolvable problems. Take, for example, division by zero, presented in its original, impeccably commented form.
"Sometimes, web applications error out," Brian writes via the Submit to The Daily WTF plug-in. "In ASP.NET, a simple web.config entry will redirect all errors to a given location like, errors.aspx. On that page, you can call Server.GetLastError() to get all the error deatils you'd like, including a full stack trace. For more advanced scenarios, you can use the Application_Error event to log errors. "
"Or, you could do what my predecessor did and rewrite the built-in behavior with something woefully inadequate. In this case, he decided to build some kind of XML object to wrap a System.Exception, then forward that error in a URL encoded with Base 64."
May 11