Tim (previously) supports a relatively ancient C++ application. And that creates some interesting conundrums, as the way you wrote C++ in 2003 is not the way you would write it even a few years later. The standard matured quickly.

Way back in 2003, it was still common to use C-style strings, instead of the C++ std::string type. It seems silly, but people had Strong Opinions™ about using standard library types, and much of your C++ code was probably interacting with C libraries, so yeah, C-strings stuck around for a long time.

When looking at the source of a major news site, today's anonymous submitter sends us this very, very mild, but also very funny WTF:

	<div class="g-vhs g-videotape g-cinemagraph" id="g-video-178_article_slug-640w"
		 data-type="videotape" data-asset="https://somesite.com/videos/file.mp4" data-cinemagraph="true" data-allow-multiple-players="true"
		 data-vhs-options='{"ratio":"560:320"}'
		 style="padding-bottom: 57.14285714285714%">

The father of the "billion dollar mistake" left us last month. His pointer is finally null. Speaking of null handling, Randy says he was "spelunking" through his codebase and found this pair of functions, which handles null.

public String getDataString() {
    if (dataString == null) {
        return Constants.NOT_AVAILABLE;
    }
    return asUnicode(dataString);
}

Tim H inherited some code which has objects that have many, many properties properties on them. Which is bad. That clearly has no cohesion. But it's okay, there's a validator function which confirms that object is properly populated.

The conditions and body of the conditionals have been removed, so we can see what the flow of the code looks like.

Today's anonymous submission is one of the entries where I look at it and go, "Wait, that's totally wrong, that could have never worked." And then I realize, that's why it was submitted: it was absolutely broken code which got to production, somehow.

Collection.updateOne(query, update, function(err, result, next)=>{
if(err) next(err)
...
})

I feel like we've gotten a few SQL case statement abuses recently, but a properly bad one continues to tickle me. Ken C sends us one that, well:

SELECT CASE h.DOCUMENTTYPE
        WHEN 2 THEN 3 WHEN 3 THEN 4 WHEN 4 THEN 5
        WHEN 5 THEN 6 WHEN 6 THEN 7 WHEN 7 THEN 8
        ELSE h.DOCUMENTTYPE
    END AS DocumentType,
    h.DOCNMBR AS DocNmbr,
    h.FULLPOLICY AS FullPolicy,
    h.BATCHID AS BatchId,
    h.OrigBatchId,
    h.UPDATEDDATE AS UpdatedDate,
    h.CUSTOMERNO AS CustomerNo,
    h.PROJECTID AS ProjectID,
    h.AMOUNT AS Amount