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.
We've talked about the For-Case anti-pattern many, many times. And while we've seen some wild variations, and some pretty hideous versions, I think we have yet to see the exact example Ashley H sends us:
Nov 25for (int i = 0; i < 4; i++) {
if (i == 0) {
step1();
} else if (i == 1) {
step2();
} else if (i == 2) {
step3();
} else if (i == 3){
finalStep();
}
}
A long time ago, Joey made some extra bucks doing technical support for the neighbors. It was usually easy work, and honestly was more about being a member of the community than anything else.
This meant Joey got to spend time with Ernest. Ernest was a retiree with a professorial manner, complete with horn-rimmed glasses and a sweater vest. Ernest volunteered at the local church, was known for his daily walks around the neighborhood, and was a generally beloved older neighbor.
Today's anonymous submitter sends us a short snippet. They found this because they were going through code committed by an expensive third-party contractor, trying to track down a bug: every report in the database kept getting duplicated for some reason.
This code has been in production for over a decade, bugs and all:
We recently asked for some of your holiday horror stories. We'll definitely take more, if you've got them, but we're going to start off with Jessica, who brings us not so much a horror as an omen.
Jessica writes:
When writing software, we like our code to be clean, simple, and concise. But that loses something, you end up writing just some code, and not The Code. Mads's co-worker wanted to make his code more definite by using this variable naming convention:
public static void addToListInMap(final Map theMap, final String theKey, final Object theValue) {
List theList = (List) theMap.get(theKey);
if (theList == null) {
theList = new ArrayList();
theMap.put(theKey, theList);
}
theList.add(theValue);
}
Betsy writes:
I found this snippet recently in a 20-year-old RPG program.
It feels like ages ago, when document databases like Mongo were all the rage. That isn't to say that they haven't stuck around and don't deliver value, but gone is the faddish "RDBMSes are dead, bro." The "advantage" they offer is that they turn data management problems into serialization problems.
And that's where today's anonymous submission takes us. Our submitter has a long list of bugs around managing lists of usernames. These bugs largely exist because the contract developer who wrote the code didn't write anything, and instead "vibe coded too close to the sun", according to our submitter.
Darren is supporting a Delphi application in the current decade. Which is certainly a situation to be in. He writes:
I keep trying to get out of doing maintenance on legacy Delphi applications, but they keep pulling me back in.
Remy's Law of Requirements Gathering states "No matter what the requirements document says, what your users really wanted was Excel." This has a corrolary: "Any sufficiently advanced Excel file is indistingushable from software."
Given enough time, any Excel file whipped up by any user can transition from "useful" to "mission critical software" before anyone notices. That's why Nemecsek was tasked with taking a pile of Excel spreadsheets and converting them into "real" software, which could be maintained and supported by software engineers.