The Daily WTF: Curious Perversions in Information Technology

The Shenanigans Handler

by Alex Papadimoulis in CodeSOD on 2009-09-30

"I'm a senior developer in a department developing, among other things, an Adobe Flex web GUI for the configuration of our products," writes Lucy. "Having worked on systems in the past which could require production fixes at 2:00 AM if something went wrong, I am a true believer in robust software (which allows you to sleep through the night). Fortunately, my current employment doesn't require that lovely on-call dedication, but it does leave me as the odd man out when trying to argue designing and implementing robust code versus time-to-ship with my team mates and manager."

Lucy continues, "I was recently addressing a reported bug when I discovered some code that finally made me realize why my methodology for robust error-handling was not important. One of my fellow developers had found a much quicker and easier method of error-handling: the shenanigans handler. What better way to describe this methodology than a quick code snippet."

112 comments - Last comment @ 2009-12-02

A First Date

by Alex Papadimoulis in CodeSOD on 2009-09-28

"I don't consider myself to be a programmer," Michael H writes, "but I have written my share of Perl and PHP. It's not that I dislike coding, it's just that I've moved to the sys admin side of things, and it's probably better for everyone that my kind doesn't write code.

"However," Michael continues, "because our IT department is so small (just myself and a programmer), my job responsibilities do include fixing hyper-critical-emergency bugs should they arise when the programmer is unavaiable. The same holds true if hyper-critical-emergency server issues arise when I'm unavailable: the programmer will jump in and do what he can."

125 comments - Last comment @ 2013-04-03

CodeThatDocumentsItselfSoWellItDoesNotNeedComments

by Alex Papadimoulis in CodeSOD on 2009-09-23

“When I first met the lead developer at my new job, we had a very long and very good conversation about code quality,” Ben Stilgar wrote. “He and I just seemed to click, especially when it came to self-documenting code: architecture should balance functionality and understandability, program flow should be optimized only after performance problem, and code should be clear and understandable, even if it takes longer to write.”

“You can imagine my excitement when it came time to opening The System, which was the lead developer’s masterpiece and culminated over a decade of design and development experience into a clean, almost-perfect application. You can also imagine my disappointment when I finally dived in and learned exactly what he meant by self-documenting code.”

189 comments - Last comment @ 2022-08-02

Loopy Validation

by Alex Papadimoulis in CodeSOD on 2009-09-21

"I work for a company that takes over the development of certain parts of our partners' websites," Clark S writes. "Often, in the process of porting code, we'll come across some strange and archaic validation files, CSS hacks, and so on. I'm pretty used to seeing bad code (that's why they're paying us, after all), and I can't say I've found anything impressively bad. Don't get me wrong: it's bad... just not The Daily WTF bad."

"Of course, all that changed when I came across the code for a certain new partner. It really threw me for a loop (no pun intended) and taught me that, apparently, I've been using for-loops wrong all these years."

123 comments - Last comment @ 2009-12-28

DELETE. No, INSERT! No, SELECT!

by Alex Papadimoulis in CodeSOD on 2009-09-14

It seemed like a good idea at the time. Why hard code all those SQL statements when you can just soft code them in a configuration file? That way, the data model can be changed without the other layers needing to know about it. It's brilliant!

Although Jan Fabry wasn't around for the "let's put all our queries in a separate file" decision, he was around for support, which was long after all the decision-makers moved on to bigger and better things. "In practice," he wrote, "the idea didn't work so well. Especially when the name, the comment and the code seem to disagree about what to do.

129 comments - Last comment @ 2009-09-27

The Ultimate State Selector

by Alex Papadimoulis in CodeSOD on 2009-09-09

One of the fundamental axioms of software development — #9 on the list, actually — is that "there is always a better way." This holds that there is no such thing as Perfect Code, only Good Code which is appropriately correct, appropriately optimized, and appropriately documented for the situation at hand. On the other hand, a lesser-known axioms (#1873, for those keeping count) is that "there is always a worse way." No matter how bad a particular block of code may seem... someone, somewhere, somehow will develop something even worse.

Of course, this being The Daily WTF, I figured that we'd be above that latter axiom. With all of the bad code published here (don't forget: submit your own!), surely we've seen the worst possible way of doing something. The Absolute Zero of bad code, if you will. I mean, once you've seen one declare-a-boolean-variable-for-every-state-and-have-if-statements-determine-the-selected-state-and-print-it-out (like this), you've seen them all, right?

166 comments - Last comment @ 2017-03-07

Recent CodeSOD