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.
Marcus inherited a big-ol-ball-of-mud PHP application. The entire thing is one difficult to summarize pile of WTF, but he searched long and hard to find one snippet that actually summarizes how awful the code is.
That snippet is this :
It had been a long meeting, and Bert was exhausted. Now, normally when a story on TDWTF starts that way, we go on to tell you about a hapless developer trapped in management hell, but this time, we're flipping the script on you: Bert was the Business Analyst on a project to enhance some self-check software for a number of supermarket chains. Ernie, the Software Engineer, was one of those braindead devs who needs everything spelled out before he'll write so much as a line of code, and Bert was much more comfortable with the looser specs in Agile projects.
Our anonymous friend writes: I was tasked with figuring out why invalid XML was being output by a homegrown XML parser. As I looked into the code, I found the way this code handles writing out XML files…
Yes, it really does open and close the file handle for every xwrite call. This means that it opens and closes it 3 times PER TAG when writing out the XML.
…Whatever remains, no matter how improbable, must be XML.
Unquestionably, a good method name should be descriptive. With today's code completion and code analysis features, almost all developers expect the names to give them at least an idea of what a method should do. When you write a library, or work on a shared codebase, it's a must- and even if one doesn't expect anybody else to use their code, it's still good not to have to remember what stuff doStuff() does.
Early in life, we learn to grab the food and then put in in our mouths. Later, it's grab the ball and then roll it. In general, you must have something before you can attempt to do something with it.
...Or so you'd think.
Steph had been at this job long enough to be fairly good at it, but not quite long enough to have peeked in all the dark corners yet. As such, when she heard that there was an issue with scheduled jobs, her first thought was to poke through cron to see if she could pick out what schedule was misbehaving. Apparently, all of them- cron was empty.
Confused, she went to her team lead Greg, asking about where she might find the scheduling setup. And that was when she heard about Travie the Whiz Kid. A junior developer with no degree, he'd been hired solely based on his ability to talk a big game about how he single-handedly saved several companies by providing them with innovative websites during the dot-com bubble... when he was twelve. The Whiz Kid was a Special Snowflake; he preferred to reinvent the wheel rather than implement stable but "boring" code. Upper management was convinced he was an unparalleled genius, and had exempted him from the usual QA standards. Unfortunately, he'd grown utterly bored with Business Intelligence and transferred to the Web team, leaving his inventions behind for Steph to maintain.
Mar 15