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.

Mar 2017

The Refactoring

by in CodeSOD on

I have certain mantras that I use to guide my programming. They generally revolve around this theme: "Thinking is hard, and I'm not very good at it; every block of code should be simple and obvious, because if it makes me think, I'll probably screw it up and break something." It's a good rule for me, and a good general guideline, but it's a little vague to implement as a policy.

Erika’s company wanted to implement this idea as a policy, so they set a limit on how many lines could be in a single method. The thinking was that if each method was short- say, under 100 lines- it would automatically be simple(r), right?


Dictionary Definition of a Loop

by in CodeSOD on

Ah, the grand old Dictionary/Map structure. It’s so useful, languages like Python secretly implement most of their objects using it, and JavaScript objects imitate it. One of its powers is that it allows you to create a sparse array, indexed by any data type you want to index it by.

Catherine’s cow-orker certainly thought this was pretty great, so they went ahead on and used the Dictionary to map interest rates to years. Years, for this application, were not tracked as actual years, but relative to an agreed upon “year zero”- the first year of the company’s operation. There was a new annual interest rate tracked for each year since.


Countup Timer

by in CodeSOD on

Dan has inherited a pile of Objective-C. That’s not the WTF. The previous developer had some… creative problem solving techniques.

For example, he needed to show a splash screen, and after three seconds, make it vanish. You might be thinking to yourself, “So I set a timer for 3000 milliseconds, and then close the splash screen, right?”


The Tokens That Wouldn’t Die

by in CodeSOD on

Expiration

Sacha received custody of a legacy Python API, and was tasked with implementing a fresh version of it.


Still Empty

by in CodeSOD on

A few months ago, Hannes shared with us some recycled code. In that installment, we learned that one of his team mates has… issues with strings. And naming things. And basic language features.

These issues continue.


WriteTenMemoryLocations

by in CodeSOD on

Let’s say you needed to initialize a buffer to be 260 bytes long, and they all should be 255. Now, you’re using a high-level language, like C#, to talk to a legacy device, so you might have to jump through some hoops to deal with the device API, but how hard could it be? A better question might be, “how hard can you make it?”

There’s an old saying: “fast, good, or cheap: pick two”. Massimo’s employer doesn’t want to be greedy, so they consistently pick one: cheap, which means they get code like this:


Cloning Date

by in CodeSOD on

We get a lot of bad date code samples. Since we all learned to read a calendar in elementary school, everyone assumes they actually understand how dates work, and then tries to codify that knowledge in code. Bad date code is like entry level awfulness, and it takes a lot to surprise me when I see bad date handling code. Mike R knows how to do it, though. He found this code buried in a 30+ file commit, with the helpful commit message, “asdf;”:

public class DateUtil {
    private DateUtil() {
    }
    public static Date setDate(Date date){
        if (date == null) {
            return null;
        }
        return new Date(date.getTime());
    }
    public static Date getDate(Date date){
        if (date == null) {
            return null;
        }
        return new Date(date.getTime());
    }
}


public class DateUtilUnitTest {

    @Test
    public void testSetDate() throws Exception {
        Date date = new Date();
        Date result = DateUtil.setDate(date);
        assertThat(date,is(result));
    }

    @Test
    public void testSetsNullDate() throws Exception {
        Date date = null;
        Date result = DateUtil.setDate(date);
        assertThat(date,is(result));
    }

    @Test
    public void testGetDate() throws Exception {
        Date date = new Date();
        Date result = DateUtil.getDate(date);
        assertThat(date,is(result));
    }

    @Test
    public void testGetsNullDate() throws Exception {
        Date date = null;
        Date result = DateUtil.getDate(date);
        assertThat(date,is(result));
    }
}