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

Sandra from InitAg (previously) works with Bjørn, and Bjørn has some ideas about how database schemas should be organized.

First, users should never see an auto-incrementing ID. That means you need to use UUIDs. But UUIDs are large and expensive, so they should never be your primary key, use an auto-incrementing ID for that.