Forums
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.
Nona writes: "this is the beginning of a 2100 line function."
That's bad. Nona didn't send us the entire JavaScript function, but sent us just the three early lines, which definitely raise concerns:
Candice (previously) has another WTF to share for us.
We're going to start by just looking at one fragment of a class defined in this C++ code: TLAflaList.
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:
Mar 26 <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