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.
Let's say your company wanted to offer special deals. When a customer calls about one of these deals, you want to play an automated customer support message using SignalWire, a tool for scripting phone voice trees.
This is a natural case for using a Map data structure. Which is what Ajay's predecessor did. They just… uh… weren't sure how to use a Map.
Efren's employer recently acquired a competitor. The competitor had been struggling for a number of years, and the acquisition was a last ditch attempt to preserve at least some of the business (a complete closure was the only other option).
Now, "struggling for a number of years" sounds fairly vague, but due to some bad database design, we actually have a clear indicator of exactly when the company gave up:
Luke has inherited a Java Struts-based application. Struts is one of the many Java web frameworks, designed around having HTTP requests trigger actions- that is routing HTTP requests to a specific function call.
Now, on one screen, the user filled in a form, and then the corresponding action on the server side needed to read the form data for an eventId and act upon it. In Struts, this can be very simple:
User interfaces tend to map fairly naturally to trees as a data structure. In the modern world where we've forgotten how to make native UIs and do everything as web applications pretending to be native, the "tree" model is explicit via the DOM. But even in native UIs, we tend to group controls into containers and panels and tabs.
Now, there may be cases where we need to traverse the tree, and trees present us with a very natural way to traverse them- recursion. To search the tree, first search the subtree. Recursion can have its own problems, but the UI tree of a native application is rarely deep enough for those problems to be an issue.
Mateus inherited some code where half the variables were named things like strAux1 and strAux2. It was a data driven application, and the data had some conventions that weren't always ideal; for example, every city also had an associated abbreviation stored in its name field, e.g., "SAO PAULO (SP)" and "RIO DE JANEIRO (RJ)".
The original developers wanted to be able to present the names of cities without the abbreviation, so they wrote this:
Correctly validating an email address, per the spec, is actually surprisingly hard. This is, in part, because there are a lot of features in the email address that nobody ever uses. Even so, you can easily get close enough with basic regex, and that's what most people do.
Niels H's predecessor wanted to go a little farther. They wanted to ensure that the supplied domain name had a valid DNS entry. Overkill? Probably. But, fortunately for them the .NET framework supplies a handy System.Net.Dns.GetHostEntry method, which resolves a domain name. That at least makes the problem easy to solve.
"QPirate" was debugging an issue with purchase order version information. The format was supposed to be "Revision#.Version#", essentially "major" and "minor" versions for the various steps as the purchase order wormed its way through the company's incredibly complicated purchasing process.
Unfortunately, that isn't what was happening. Many numbers behaved in unexpected ways when they were versioned too many times. QPirate dug in, and found this:
Before RESTful web services and JSON as a serialization format, XML was going to conquer the world. Circa 2001, I remember going to user's groups only to hear about how XML was going to allow legacy mainframes to be connected to modern applications (without discussing the fact that the legacy mainframe still needed maintenance and code support). These days, XML is (nearly) dead, and lighter-weight markup languages have replaced it, including JSON.
Which brings us to this method, from Chris:
Andy found this simple function in a C project he's working on.
Dec 23void clearVal(int x) {
x = 0;
}
Mike's team had a new hire. They did great on the interview, really shined in the coding challenges, so it was a no-brainer hire. In the middle of on-boarding, the team got slammed, so this new hire ended up being left to fend for themselves.
This was a mistake.
We often talk about dates and timekeeping as extraordinarily difficult tasks. And, at least in part, that may have to do with their origins as legacy technologies in the most legacy sense: we have strong evidence of calendar systems all the way back into the Neolithic period, and maybe some hints of them as far back as the Paleolithic. Literally, stone age technology, still in use today.
I wonder if that's why calendar's hold such a mystical hold over us? Many of us likely remember the New Age predictions that 2012 was going to mark the end of the world or some great reconfiguration of the world, simply because it marked the end of a cycle in the Mayan Calendar. Before that, prophecies centered on the year 2000, not just because of the Y2K bug, but simply because it's a round number and people felt like that's a good place to call it. Before that, there was the astrological predictions of the Age of Aquarius (which may fall anywhere from 1844 to sometime in the 24th century, but was real popular for a minute in the 60s and 70s). And we can walk farther back into history, finding eschatological predictions centered around significant dates.
"Generic exception handlers" sound like an oxymoron, but are a weirdly common pattern in web development. ASP .NET, for example, has a global.asax file, which can contain an Application_Error method. In practice, this is meant to handle all the otherwise unhandleable errors- each individual endpoint should still do exception handling for all the errors it can, but the errors that are impractical to handle locally, like the database being inaccessible, bubble up to your generic handler.
Of course, it's important that the generic handler actually handle the exception. Which brings us to George's submission, an ASP .Net error handler.
Before today's article, I'm gonna humblebrag a bit, minus the humble part. Peregrine launched last night, at 2AM, and by 3AM, we had communication with the spacecraft. I have done very little software on this particular mission, but code I touched is in space right now. My name is on a plaque on that lander. Also, the code I touched has no control over the mission, and is in no way, shape, or form in the control loop, so if anything goes wrong it's definitely not my fault.
Mac bears some responsibility for today's code, in that, he "fixed" it. That is to say, he was working on an unrelated bug, but this particular block of code was causing additional problems, so he did the bare minimum to make it stop bothering him so he could work on his actual ticket.
This JavaScript running on their page would allow the user to check a checkbox, navigate away from the page, and then if they hit "back" (something Mac was doing a lot while debugging), the checked checkbox would gradually migrate down the page for some weird set of JS and CSS reasons.
Christian works on an application that has some unusual conventions. For example, while I've seen many a codebase that Hungarians their private member variables like _myPrivateMember, his team did the opposite: myPrivateMember_.
Someone on the team had a problem: they needed to verify that at least one checkbox was checked. This was their solution to that, in C#:
Matteo's company hired a Highly Paid Consultant. The HPC came in, took one look at their C# codebase, and said, "You're doing everything wrong. But don't worry, I can fix it!"
So he "fixed" it.
Alyssa inherited some code from… well, she isn't entirely sure from whom. There are names that come up in git blame, but even for some more recent commits, Alyssa has no idea who they are. Contractors? Interns? Randos pulled in off the street and handed a keyboard?
Based on the code quality, the last option is surprisingly likely.