Another day, another terrible way to validate integers. Today's submission comes from Sluiper.

This approach, at least, contains a mild bit of cleverness. It's not the good kind of cleverness that makes a complicated problem more clear and easier to understand, but the bad kind that exploits assumptions about low-level technical details.

Sandra, still at InitAg, has to work with Brad. Some time ago, Brad was assigned a slew of front-end development tasks, since he's a web developer. But Brad isn't a front-end developer, and doesn't really have a good grasp of front-end development. Management isn't clear on the difference: "Aren't you a web developer? I don't care which end you use, just develop." Brad is also game to tackle whatever task is assigned to him, regardless of whether he has any sense of how to solve the problem.

When Brad needed to display data on a map, the requirements wanted the map layers to be distinguished by color. So Brad did the usual thing one might do in this situation: he created a gigantic array of all possible colors that might be used on the map. Actually, he created two: colors and colorsBlackWhite.

Pieter-Jan needed to add some features to a PHP-based site for managing student assessments. Students would complete projects, submit them, and then receive feedback from their peers. The number of peers providing feedback is variable, so the application has to manage that. Which, you might be thinking, "that sounds like not a big deal to manage," but for Pieter-Jan's predecessor, it seems like it may have been.

    if($i > '0') {
        $team=array($studentName1,$content1,$motivation1,$isTeamMate1);
    }
    if($i > '1') {
        $team=array($studentName1,$content1,$motivation1,$isTeamMate1,$studentName2,$content2,$motivation2,$isTeamMate2);
    }   
    if($i > '2') {
        $team=array($studentName1,$content1,$motivation1,$isTeamMate1,$studentName2,$content2,$motivation2,$isTeamMate2,$studentName3,$content3,$motivation3,$isTeamMate3);
    }

Stack V supports a web application that accepts regexes from users. For legacy reasons, the users must supply the surrounding / characters, as well. There was some validation to ensure that the inputs were correct, but QA discovered that invalid regular expressions were getting through.

They filed a bug, it got triaged, and then shipped off to a contractor to patch. This was the contractor's solution:

A true confession: I absolutely cannot successfully edit a crontab file without spending a lot of time reading docs on what all the little date/time/interval flags mean. Partially, it's just that I don't do it very often, but mainly the information flies right out of my head once I've done it. I can absolutely understand why someone might want to write a little helper program to help themselves manage their crontab.

I just can't understand why they'd write this one, sent to us Beorn. We'll have to take this one in chunks, because it's 18,905 lines.

A former co-worker of David S wanted to check for nulls, and apparently, they had just learned about the ternary operator, so they wanted to combine these actions. That, itself, isn't a WTF- using ternaries to coalesce nulls is a time-honored tradition and generally pretty effective.

Let's see how this Java developer approached it: