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.

Aug 2010

Command 696

by in CodeSOD on

Think of all those old applications you’ve had to maintain. You know the type: the ones written by long-forgotten developers in long-lost languages. The ones that, after spending days searching for that one line of code that needs to be changed, you frustratingly decree “this f%*#@ thing needs to be rewritten.” And, naturally, the ones that never are, nor never will be rewritten.

Call it luck or persistence, but after dozens and dozens of maintenance requests over the years, Israel Brewster finally was given the opportunity to rewrite an application. From scratch. And the right way, this time. No shoddy VB6 front-end; no horribly-designed SQL Server 2000 (only) database; and certainly no Microsoft Access-based administration tool.


Masquerading as a Loop

by in CodeSOD on

"While digging through some inherited code," writes Joe "M2tM" Smith, "I encountered a conditional masquerading as a loop."

"Thankfully, the fellow responsible is 'no longer with us', and I suppose this type of code stands as silent testament to why. This interesting loop is only created so the break keyword can be used as an elaborate GOTO."


Swallowed by the Beast

by in CodeSOD on

Paul was having a good morning.  It was a beautiful day outside, he managed to shave 15 minutes off his commute, and even the local coffee shop had his favorite donut in stock.  All of that changed when he got his first support call of the day.  It was from a client running "the beast" product.  "The beast", as Paul and his coworkers nicknamed it, was a legacy version of their application developed somewhere overseas years before Paul was hired, by hundreds of poorly trained, and probably poorly paid, developers.  The company's sales team actively encouraged clients to upgrade from the legacy application, but a select few had resisted.

"The beast" had a reputation for containing some of the worst code Paul had ever seen and every time he had to support it, he felt like he needed a shower afterwards.  It was during his fourth hour of debugging that Paul came across a previously unvisited function shown below. 


Avoiding Magic Constants

by in CodeSOD on

Everyone knows that "Magic Numbers" are bad, Bad, BAD! Take, for example, dividing something into quarters. Because including the literal "4" in your code would be a Magic Number, many developers agree that it's best to define a constant named "FOUR", and then use that constant instead. Makes sense, right?

Wrong! The problem with using "FOUR" is that, like "4", it's a Magic Constant. While not nearly as bad as Magic Numbers, Magic Constants certainly aren't elegant. Fortunately, Allen's colleague has provided us all with a valuable lesson the proper use of Magic and Non-Magic constants. Read it, and learn.


Role-based Canary

by in CodeSOD on

Role-based security requires, at a minimum, two key elements: users and roles. Roles (such as Administrator, Clerk, and ViewOnlyUser) are defined by the application code and then assigned to users to restrict which functions of the application they may use. It's a pretty simple concept that involves all of two database tables, or one if the user names come from some external source like Active Directory.

In Adam's case, the Role-based security feature served as a coalmine canary in the application he was tasked with reviewing. Although it passed all of the test cases — employees could only do certain things, customers could do other things, etc. — there was one fundamental flaw with the system. See if you can spot it.


The Arralphalet

by in CodeSOD on

James sent in today's snippet with virtually no introduction; just six, measly words: "the grass is definitely not greener." Normally, that'd be a bit frustrating, since it's always nice to know a little history or background about the code. But like those six word stories, James told the classic tale of the young and burgeoning software developer who’s always looking to expand his professional purview by seeking out new opportunities to learn and sharpen his skills, only to find his efforts frustrated by a “seemed good on paper” job that leads to nowhere – or worse – towards destitute and despair.

Well, either that, or this code really speaks for itself. Maybe it's the generic Util class which acts as a dump for random methods. Perhaps it's the alphabet array with an extra Z. Or it could be that method for turning letters into numbers.


Try... Catch-em-all

by in CodeSOD on

"Recently, I inherited an ASP.NET web application that hadn't been touched in many a year," wrote Scott Schottler, "I was pleasantly surprised to see that, not only did it successfully convert from a Visual Studio 2003 project, but that it actually built without errors."

"Of course, my excitement soon waned when I looked into the code. Now we've all seen the Try-Catch-Gulp pattern, but this is ridiculous."


Uncovering Nothing

by in CodeSOD on

Remi works on one of his country's largest Internet Service Providers, and has the fortune to be on an elite team that focuses on agile development. Or misfortune, depending on how you look at it: at his company, "agile development" actually means "we need that in two weeks".

One of Remi's first assignments was to fix an "emergency" on one of the ATM Addressing systems. Apparently, the application was coming up with incorrect routing data. After a solid day-and-a-half of digging through Visual Basic code that called SQL Server stored procedures which called VB-based COM objects which called more stored procs, Remi found a weird table ("Cal_ATM") that was referenced from an externally-linked database, and the data in that table was completely out of date.