The Daily WTF: Curious Perversions in Information Technology

Philegex

by Remy Porter in CodeSOD on 2018-04-30

Last week, I was doing some graphics programming without a graphics card. It was low resolution, so I went ahead and re-implemented a few key methods from the Open GL Shader Language in a fashion which was compatible with NumPy arrays. Lucky for me, I was able to draw off many years of experience, I understood both technologies, and they both have excellent documentation which made it easy. After dozens of lines of code, I was able to whip up some pretty flexible image generator functions. I knew the tools I needed, I understood how they worked, and while I was reinventing a wheel, I had a very specific reason.

Philemon Eichin sends us some code from a point in his career where none of these things were true.

17 comments - Last comment @ 2018-05-01

If Not Null…

by Remy Porter in CodeSOD on 2018-04-26

Robert needed to fetch some details about pump configurations from the backend. The API was poorly documented, but there were other places in the code which did that, so a quick search found this block:

var getConfiguration = function(){
    ....
    var result = null;
    result = getPumpConfiguration (areaID,subStationID,mngmtUnitID,lastServiceDate,service,format,result);
    result = getPumpConfiguration (areaID,subStationID,null,lastServiceDate,null,format,result);
    result = getPumpConfiguration (areaID,subStationID,null,lastServiceDate,service,null,result);
    result = getPumpConfiguration (areaID,subStationID,mngmtUnitID,lastServiceDate,null,null,result);
    result = getPumpConfiguration (areaID,subStationID,null,lastServiceDate,null,null,result);
    return result;
}

25 comments - Last comment @ 2018-05-15

A Problematic Place

by Josh Cox in CodeSOD on 2018-04-19

In programming, sometimes the ordering of your data matters. And sometimes the ordering doesn’t matter and it can be completely random. And sometimes… well, El Dorko found a case where it apparently matters that it doesn’t matter:

DirectoryInfo di = new DirectoryInfo(directory);
FileInfo[] files = di.GetFiles();
DirectoryInfo[] subdirs = di.GetDirectories();

// shuffle subdirs to avoid problematic places
Random rnd = new Random();
for( int i = subdirs.Length - 1; i > 0; i-- )
{
    int n = rnd.Next( i + 1 );
    DirectoryInfo tmp = subdirs[i];
    subdirs[i] = subdirs[n];
    subdirs[n] = tmp;
}

foreach (DirectoryInfo dir in subdirs)
{
   // process files in directory
}

45 comments - Last comment @ 2018-04-23

Breaking Changes

by Remy Porter in CodeSOD on 2018-04-17

We talk a lot about the sort of wheels one shouldn’t reinvent. Loads of bad code stumbles down that path. Today, Mary sends us some code from their home-grown unit testing framework.

Mary doesn’t have much to say about whatever case of Not Invented Here Syndrome brought things to this point. It’s especially notable that this is Python, which comes, out of the box, with a perfectly serviceable unittest module built in. Apparently not serviceable enough for their team, however, as Burt, the Lead Developer, wrote his own.

23 comments - Last comment @ 2018-04-25

All the Things!

by Remy Porter in CodeSOD on 2018-04-16

Yasmin needed to fetch some data from a database for a report. Specifically, she needed to get all the order data. All of it. No matter how much there was.

The required query might be long running, but it wouldn’t be complicated. By policy, every query needed to be implemented as a stored procedure. Yasmin, being a smart prograammer, decided to check and see if anybody had already implemented a stored procedure which did what she needed. She found one called GetAllOrders. Perfect! She tested it in her report.

28 comments - Last comment @ 2018-04-25

Without Context

by Remy Porter in CodeSOD on 2018-04-10

When writing up a Code SOD, a big part of the goal is to provide context for the bad code. Why is it bad, what would be better,, etc. In other words, we need to… ShowContext. Vasco O has exactly the method for that.

protected string ShowContext(string context)
{
    if (!string.IsNullOrEmpty(context))
    {
        return string.Format("{0}", context);
    }
    else
    {
        return string.Empty;
    }
}

34 comments - Last comment @ 2018-06-07

30 Days

by Remy Porter in CodeSOD on 2018-04-04

Tim B did a little work with an e-learning vendor, with some very old code. The code in question happened to be so old that “this is server side JavaScript” was a horrifying novelty when they wrote it, instead of a standard deployment option via Node.

The code in question is bad date handling code, which isn’t impressive. What is impressive is that it demonstrates a terrible approach to dates which I’ve never seen before. It doubles as a terrible approach to arrays which I have seen before, but… it remains special.

50 comments - Last comment @ 2018-04-10

A Repeated Save

by Remy Porter in CodeSOD on 2018-04-03

Ian S was going through the portfolio of applications maintained by his company, and stumbled across one that… well, from what he could tell, wasn’t written by a developer so much as spawned by an accident. 90% of the code was copy-pasted from somewhere else in the code, flow-of-control mostly used Exceptions as an attempt at doing GOTO-style logic, and there were piles of unused variables or variables used before initialization. Some modules/packages in the application were full of syntax errors, which implied that they weren’t actually included or used anywhere.

From that mess, Ian extracted this.

17 comments - Last comment @ 2018-04-03

Recent CodeSOD