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.
Rachel worked on a system which collected data about children, provided by parents and medical professionals. There was one bug that drew a lot of fire: no one could report the age of a child as less than one. That was a problem, as for most of their users, child ages are zero-indexed. One of the devs picked up the bug, made a change, and went on to the next bug.
This was the fix:
Michael had a co-worker who was new to the team. As such, there was definitely an expected ramp-up time. But this new developer got that ramp up time, and still wasn't performing. Worse, they ended up dragging down the entire team, as they'd go off, write a bunch of code, end up in a situation that they couldn't understand why nothing was working, and then beg for help.
For example, this dev was tasked with adding timestamps to a set of logging messages. The logs had started as simple "print" debugging messages, but had grown in complexity and it was time to treat them like real logging.
Joseph sends us a tried and true classic: bad date handling code, in JavaScript. We've all seen so much bad date handling code that it takes something special to make me do the "confused dog" head tilt.
Nov 24 var months=new Array(13);
months[1]='January';
months[2]='February';
months[3]='March';
months[4]='April';
months[5]='May';
months[6]='June';
months[7]='July';
months[8]='August';
months[9]='September';
months[10]='October';
months[11]='November';
months[12]='December';
var time=new Date();
var lmonth=months[time.getMonth() + 1];
var date=time.getDate();
var year=time.getFullYear();
document.write(lmonth + ' ');
document.write(date + ', ' + year);
Today's anonymous submitter supplies us with a classic antipattern: padding via switch:
string TransactionOrder = (string)dr["TransactionOrder"].ToString().Trim();
switch (TransactionOrder.Length)
{
case 1:
TransactionOrder = "000" + TransactionOrder;
break;
case 2:
TransactionOrder = "00" + TransactionOrder;
break;
case 3:
TransactionOrder = "0" + TransactionOrder;
break;
default:
TransactionOrder = TransactionOrder;
break;
}
Phil's company hired a contractor. It was the typical overseas arrangement: bundle up a pile of work, send it off to another timezone, receive back terrible code, push back during code review, then the whole thing blows up when the contracting company pushes back about how while the code review is in the contract if you're going to be such sticklers about it, they'll never deliver, and then management steps in and says, "Just keep the code review to style comments," and then it ends up not mattering anyway because the contractor assigned to the contract leaves for another contracting company, and management opts to use the remaining billable hours for a new feature instead of finishing the inflight work, so you inherit a half-finished pile of trash and somehow have to make it work.
Like I said, pretty standard stuff.
One of the long-tenured developers, Douglas at Patrick's company left, which meant Patrick was called upon to pick up that share of the work. The code left behind by Douglas the departing developer was, well… code.
For example, this block of Java:
Rob's co-worker needed to write a loop that iterated across every element in an array. This very common problem, and you'd imagine that a developer would use one of the many common solutions to this problem. The language, in this case, is JavaScript, which has many possible options for iterating across an array.
Perhaps that buffet of possible options was too daunting. Perhaps the developer thought to themselves, "a for each loop is easy mode, I'm a 10x programmer, and I want a 10x solution!" Or perhaps they just didn't know what the hell they were doing.
Alice has the dubious pleasure of working with SalesForce. Management wants to make sure that any code is well tested, so they've set a requirement that all deployed code needs 75% code coverage. Unfortunately, properly configuring a code coverage tool is too hard, so someone came up with a delightful solution: just count how many lines are in your tests and how many lines are in your code, and make sure that your tests make up 75% of the total codebase.
Given those metrics, someone added this test:
Eli sends us something that's not quite a code sample, despite coming from code. It's not a representative line, because it's many lines. But it certainly is representative.
Here's the end of one of their code files:
As often happens, Luka started some work but didn't get it across the finish line before a scheduled vacation. No problem: just hand it off to another experienced developer.
Luka went off for a nice holiday, the other developer hammered away at code, and when Luka came back, there was this lovely method already merged to production, sitting and waiting:
"We use a three tier architecture," said the tech lead on Cristian's new team. "It helps us keep concerns separated."
This statement, as it turned out, was half true. They did divide the application into three tiers- a "database layer", a "business layer", and a "presentation layer". The "database layer" was a bunch of Java classes. The "business layer" was a collection of Servlets. And the "presentation layer" was a pile of JSP files.
Alexandra inherited a codebase that, if we're being kind, could be called "verbose". Individual functions routinely cross into multiple thousands of lines, with the longest single function hitting 4,000 lines of code.
Very little of this is because the problems being solved are complicated, and much more of it is because people don't understand how anything works.