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.
Jonathan did a double-take when he glanced over this function:
Sep 08
Public Sub KillTheChildren()
Dim objIntegrationAccount As IntegrationAccount
For Each objIntegrationAccount In mcolItems
Set objIntegrationAccount = Nothing
Next
Set objIntegrationAccount = Nothing
End Sub
When I'm creating a function, I try to make sure it passes two simple tests:
That said, this code that Paul G. sent in doesn't meet my criteria.
If I had a dollar for every time I've seen someone doing custom date and time parsing, I'd have somewhere between eight and ten dollars. It's just not something you see much of these days. All major programming languages have built-in support for parsing dates, times, currency, etc., and programmers are pretty good about using them.
When I have to parse a date, I take the simplest approach I can – something like Date.Parse(dateString). This is because I am a programmer and not an engineer. An engineer on Benjamin B.'s team uses a different approach. It works incredibly well! It says so right in the snippet below!
Call it confirmation bias, call it superstition, but as developers and human beings, we're all susceptible to it. Say you're working on a particularly tricky bit of code, so you've fallen back on the "try all kinds of crazy crap until it passes the specific test case" method, an invaluable tool for all developers. You find an approach that works, and while you're not sure exactly why it worked, you keep it in mind for the future.
In Robert L.'s case, he found the snippet below:
Reminder: Survey Time! Please take a few moments to fill out the brief The Daily WTF Reader Survey. Thanks!
"About halfway through an important project at Initrode," wrote Pat P., "the consultant team was augmented by a new member. Nothing notable you might say except for one fact: she was a girl. And not just any girl. She was attractive. Very very attractive. And if it wasn’t unjust enough that all developers were tormented by the daily sight of something so charming and yet elusive, Rachelle - the new team member, proved to be a very competent and effective programmer."
I can't imagine a world without content filtering. Just think of all innocent children, parents, and grandparents that would be irreparably harmed from seeing those certain vile combinations of letters that we call "swear words." While I've been forever changed by seeing such words, I long for the days when I thought that "f...ing" was just a short way of writing floccinaucinihilipilificating. And I truly believe that it's my duty to protect the innocent from being exposed to those dastardly words and let them believe that an f-bomb simply refers to a friendly-bomb, as in, a shower of hugs and kisses.
Paul G. is in a similar position. When their application was moving to a new architecture, he was in charge of migrating the content filtering code. Since he hadn't had to look at that code in a while, he searched the entire codebase for the regular expression "f..king." OK, fine, he searched for the actual word; I'm just pulling it out for those of you with content filters at work. Anyway, his search led him to the following:
"When we interview people," cablecar wrote on the Sidebar, "we give them simple programming tasks to test their ability. The below code was an attempt to solve a problem I found on Project Euler. It's from a candidate for a senior development position with '10 years of PHP' experience.
As the seasons change and years pass, trees accumulate rings that can be used to determine the age of the tree. This is a result of seasonal growth — the inner section of each ring is formed in the early part of the rapid growth season; this wood is called "early wood" (*snicker*). Then as the temperature changes and growth slows, the darker outer portion of the ring forms ("late wood"). And who can forget the classic scene from Vertigo in which Kim Novak's character hints at a passion for dendrochronology as she finds the years of her birth and death on the rings of a tree. Why do I bring this up? Because seeing bits of the past frozen in time is fascinating.
Nathan B. was called for help when an internal Access application was hanging. After some tinkering, he found that it wasn't hanging, as three reports had successfully printed and the fourth was on its way — it was just taking three times longer than it usually did. Sadly, the reports had to be done that day, and at this pace, they'd still be printing until 6:00 the next morning.
For several years, Clint's company has been working on a game that's undergone several engine and tool changes. And I'll stop you right there- it's not Duke Nukem Forever because this game exists, and has been released.
If you've ever seen or worked in a codebase that has seen significant change, you know that the replaced component is seldom completely exorcised. Little hooks from it remain in some random function that need to stay there or else everything breaks. To give you an idea of some of the changes this game's codebase has seen, have a look at this:
Michael F. arrived to an ugly sight — an inbox full of messages with the same subject line. "ERROR: Invalid data near '<Carrier '" And that could only mean one thing. The shipping software company had released a patch to their web service. Having suffered through updates of ClearPath Logistics' software before, he knew exactly how this was going to go.
First, he typed up his usual message that boils down to (and I'm paraphrasing here) "WTF?" He had a contact, Dogan, that he usually alerted when their patches broke things.