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.

Jan 2017

Popping a Plister

by in CodeSOD on

We live in a brave new world. Microsoft, over the past few years has emphasized, more and more, a cross-platform, open-source approach. So, for example, if you were developing something in .NET today, it’s not unreasonable that you might want to parse a PList file- the OSX/NextStep/GNUStep configuration file format.

But let’s rewind, oh, say, five years. An Anonymous reader found a third-party library in their .NET application. It never passed through any review or acquisition process- it was simply dropped in by another developer. Despite being a .NET library, it uses PLists as its configuration format- despite .NET offering a perfectly good in-built format. Of course, this C# code isn’t what we’d call good code, and thus one is left with an impression that someone hastily ported an Objective-C library without really thinking about what they were doing.


Eventful Timing

by in CodeSOD on

I once built a system with the job of tracking various laboratory instruments, and sending out notifications when they needed to be calibrated. The rules for when different instruments triggered notifications, and when notifications should be sent, and so on, were very complicated.

An Anonymous reader has a similar problem. They’re tracking “Events”- like seminars and conferences. These multi-day events often have an end date, but some of them are actually open ended events. They need to, given an event, be able to tell you how much it costs. And our Anonymous reader’s co-worker came up with this solution to that problem:


Extended Conditions

by in CodeSOD on

Every programming language embodies in it a philosophy about how problems should be solved. C reduces all problems to manipulations of memory addresses. Java turns every problem into a set of interacting objects. JavaScript summons Shub-Niggurath, the black goat of the woods with a thousand young, to eat the eyes of developers.

Just following the logic of a language can send you a long way to getting good results. Popular languages were designed by smart people, who work through many of the problems you might encounter when building a program with their tools. That doesn’t mean that you can’t take things a bit too far and misapply that philosophy, though.


Mapping Every Possibility

by in CodeSOD on

Capture all

Today, Aaron L. shares the tale of an innocent little network mapping program that killed itself with its own thoroughness:


Sche-ma

by in CodeSOD on

In the early 2000s, it was a time of darkness, a world of fear, it was the age of XML. As someone who was just entering the industry at the time, you couldn’t type three lines of code without a PHB asking, “Have you considered using XML for this?” Since this was 2002, “this” was likely trying to find a way to emulate the marquee tag in JavaScript, the answer was usually, “No,” at which point you’d be reminded that we should be using XML for everything, so throw it out and start over in XML.

One of the key selling points of the grand power of XML was the idea of schemas. These magical little files allowed you to use XML to specify the structure of some other XML, and then validate various XML documents against that schema. Combined with the ability to use namespaces, this was truly the One Format to Rule Them All™.


Do You Think This is a Game?

by in CodeSOD on

We’ve passed Christmas and made our way through a Steam sale with our wallets mostly intact, and now most of us have a pile of games that we’ll probably never actually play.

Game programming is hard. Setting aside the “cultural” problems in the industry- endless crunches, compensation tied to review scores, conflicts between publishers and studios, and a veneer of glamour over unglamorous work- the actual work of developing a game is a hard job.