Recent CodeSOD

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.

Jul 2007

Diary of a Programmer Analyst

by in CodeSOD on

Well over a decade ago, James Kirk started his career at as a lowly Programmer at a large company. In a short six months, through lots of hard work and dedication, his title and pay was upgraded to Programmer Analyst. At that point, he was happy with his career. Then came the hiring freeze. And the wage freeze. And the extension to the wage freeze. As the moths turned into quarters and the quarters into years, James saw less and less of an opportunity for any sort of advancement.

Of course, being that this is all ancient history, James had forgotten all about it. Recently however, a friend of his started working at James’ old workplace and stumbled upon some of his unhappiness…


EnterFlag Technology

by in CodeSOD on

Jan Krüger shares with us the unique EnterFlag Technology that he came across recently ...

"We all know it is very difficult to validate user input on web pages. Specifically, a problem that has been baffling scientists for years is finding out whether the input form on the page to be displayed was submitted in the current request. Luckily, this problem is now solved once and for all, thanks to a colleague of mine, who was tasked with preventing the form validation code from showing error messages when the form was not even submitted yet.


One at a Time

by in CodeSOD on

While looking for a mortgage company to refinance his loan, Evgeny Potashnik came across Australian Mortgage Options. They seemed decent enough; they even had an online loan management site. Curious to see what it offered, Evgeny took a peek…

The first thing he was greeted with on their loan service page was a rather peculiar login. Customers are asked to enter their loan number, one digit at a time:


Yet Another Operator Overloading Abuse

by in CodeSOD on

If you've worked as a C++ programmer for long enough, I'm sure you have plenty of stories about operator overloading abuse. Today, Jake Wyland shares the worst abuse he's seen to date ...

"The company I used to work for went on a hiring binge to staff up for a big project. The work required a lot of domain experience working with a gargantuan plug-in API. To make learning the API easier, we decided to have weekly code excursions where people would come in and present the code they were working on and show off how to use the portion of the API they were working on. During one such code excursion, I saw the following code scroll by in the image projected on the wall:


Tenth Time's The Charm

by in CodeSOD on

If you’ve ever noticed how completely unreliable computers are – you know, performing completely random and unpredictable actions when given a simple, explicit instruction – then you’ll appreciate today’s snippet from John P.

Today’s code was uncovered in a web application and attempts to solve the well-known problem of DateTime.Parse: in the event that the method fails the first time, it will probably correctly parse a string the tenth time.


Protected Code

by in CodeSOD on

Every once in a while, we have no choice but to write “dangerous” code. The type of code that, when used improperly, can wreak all sorts of havoc on the system. Purging audit trail records, fast-swapping statuses, or, like in today’s example, code that toggles an object’s "IsUpdated" property regardless of whether that object has been updated.

It’s a good idea to protect such code, perhaps using access specifiers like “private” or “internal” or even runtime-enforced security like the System.Security.CodeAccessPermission namespace. Or, one could go the route of Riaan Hanekom's predecessor and use some sort of… password protection?


Not the Most Thought Out Enumeration

by in CodeSOD on

Chris M is part of team that’s responsible for maintaining a giant mess that was once a fairly simple C++ application. Like so many organically grown behemoths, this application has its share of bad and rotting code.

Today’s example, however, is neither bad nor rotting. It’s simply bizarre. Code that never should have been, and that no sane person ever could have written …


What Where We Thinking?

by in CodeSOD on

Back in the 90's, Andreas was working on various SmartCard projects. Most of it involved programming 8051 microcontrollers. One particular project required him to replace magnetic stripe card readers with SmartCard readers while emulating the exact behaviour of the previous hardware.

After weeks of back and forth between the customer and him, his final job was to clean up the code and comments for the final release. And this is when he found this little nugget ...


Many Shades of Cout

by in CodeSOD on

For the most part, the Message Queue Processor at Andy's company is not a terrible application to work with. Most changes – such as setting up a new queue, changing trigger times, and so forth – can be done by changing configuration files. At least, that was Andy's opinion before having to make a change to its code…

Andy needed to add in support for serializing on multiple recipients, which mostly meant that he’d have to throw together an overload for the Serialize method. Not a big deal, until he made the fatal mistake of declaring a variable named cOut:


Classic WTF: The Forbidden Parameter

by in CodeSOD on

Happy Independence Day, U.S. readers! And for you non-U.S. readers, Happy .. errr ... Regular Day of the Week! The Forbidden Parameter was originally published way back on June 16th, 2006 ...


When Steve Mitcham started at a new job a little while back, he spent some time reading through the documentation and implementation guide for the enterprise framework that the company developed in-house. There were a few things that seemed off, but one thing in particular stuck out ...


Extra Sensitive Case Insensitivity

by in CodeSOD on

How often do you look within the bowels of your age-old "helper" classes? For most, including Sean, the answer is almost never. Why bother when it works just fine? Well, one reason might be to see what interesting techniques your predecessors employed in solving the simplest of problems... such as a case-insensitive search...

Fortunately, the original programmer never had to search for an 8 character string ...