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.
Sometimes, we get a submission and the submitter provides absolutely no context. Sometimes, the snippet is even really short, or the problem is "subtle" in a way that means we can't spot it when skimming the inbox.
Which is why this submission from "Bus Error" has been sitting in the inbox for seven years, and why just today, as I was skimming old submissions, I finally saw what was great about this little block of C-code.
One of the biggest challenges in working with financial data is sanitizing the data into a canonical form. Oh, all the numeric bits are almost always going to be accurate, but when pulling data from multiple systems, is the name "John Doe", "John Q. Doe", "J. Doe"? What do we do when one system uses their mailing address and another uses their actual street address, which might use different municipality names? Or in all the other ways that important identifying information might have different representations.
This is Andres' job. Pull in data from multiple sources, massage it into some meaningful and consistent representation, and then hand it off to analysts who do some capitalism with it. Sometimes, though, it's not the data that needs to be cleaned up- it's the code. A previous developer provided this Visual Basic for Applications method for extracting first names:
"When handling user input, make sure to handle exceptions," is good advice. But sometimes, that can lead you astray.
Bob is a junior programmer surrounded by veterans with 20+ years of experience. Normally, this means that when there's something unusual in the code, Bob writes it off as the senior devs vast experience. But not this time.
Yesterday, among many many problems in that gigantic switch statement, we highlighted one line that was a real mess of mixing Java's primitive/object types.
(new Integer(1).equals(job.getSource().getLength()))
If you have an object, say a Job, which can be in multiple states, you'll frequently need to execute different code, depending on the state. Enter the ever useful switch statement, and all those problems are solved.
Or are they? Reva found this Java code. Enjoy your 112 line switch statement:
Just because someone writes in C, and not some more modern language doesn't mean they're going to be an expert in how to operate on binary values.
Carl W found this bit of C code with a simple goal: count the number of trailing zeroes in a 32-bit integer. At least, that's what the function name tells us. Reading the logic, I'm less certain.
Repentinus submitted a pull request to a project he was working on. The Python code Repentinus submitted was this:
Jul 21if unit.is_translated() and (self.include_fuzzy or not unit.is_fuzzy()):
return unit.target
else:
return unit.source
Today, let's just start with a single line of Java code, from Rich.
T oldValue = (T) (configItems.get(configKey) == null ? null : configItems.get(configKey));
Some languages support operator overloading. Others, like Java, do not. There are good arguments on either side for whether or not you should support the feature, but when you don't, you need an easy way to get the effects of operators without the syntactic sugar.
For example, if you have a custom class, and you need a way to perform comparisons on them, you may choose to implement the Comparator interface. This allows you to add some kind of comparison to an object without actually touching the object's implementation. For example, you might do something like:
One of the advantages of interpreted languages, like Python, is that when your vendor ships a tool that uses Python… you can see how the Python bits actually work. Or maybe seeing how the sausage is made is a disadvantage?
Delana's vendor tool needs to determine the IP address of the computer in a platform independent way. The "standard" way of doing this in Python is to check the computer's hostname then feed that into a function like one of these which turns it into IP addresses.
Kaci had one of "those" co-workers who didn't believe in source control. As you modified code, you'd just comment out bits and pieces, maybe replace some of it. That way you could see how the code evolved without having to learn how to use git log correctly.
At least, that was the rough argument. But it meant that when Kaci wanted to understand why this block of PHP code existed, she needed to ask the developer:
Sometimes, readers submit code and say, "every line is wrong!" Usually, they mean that every line contains a bad choice, or represents a bad way of accomplishing the program's goal, or there's a series of compounding mistakes.
David sends us a block which… well, yes, every line is wrong, because every line contradicts every other one.
I have a very casual interest in magic tricks. I certainly don't have the patience to actually learn to perform any well, but I enjoy watching them and piecing together how they're done. What really captures my interest is that actually performing a trick is about following a well-defined path, and by following that path you can achieve incredibly impressive effects. But if you just see the effect without understanding the path, and try and replicate it yourself, it's probably not going to work.
In programming, there are certain things I consider "frickin' magic". They can create impressive effects, but the actual mechanism is concealed behind enough layers of abstraction that, if you don't stick to the carefully defined path, you can make some mistakes.
Lets say you have a 64-bit integer. You want the first 42-bits. Now, if your language has a bitshift operator, you'd be tempted to do something like largeNumber >> 22.
But what if your language also has all sorts of advanced stream processing and map functions? It'd be a shame to not use those. Tarah's shop uses Rust, and thus they do have all those exciting advanced stream processing. Her co-worker decided they just needed to be used:
One of the big pieces of advice about using exceptions and errors is that they shouldn't be used for flow control. You catch an exception when an exceptional event happens, but you don't, for example, throw an exception to break out of a loop.
Unless you're Python, which throws exceptions to break out of loops. That's just how iteration works. But we're not here to talk about Python.
Alex sends us some Objective-C code which… well, let's just say that the code is suspicious looking, but there's nothing clearly bad about it.
+(const char*)st:(NSArray*)a a:(int)i
{
@try
{
return ([a objectAtIndex:i]==[NSNull null])?"":[[a objectAtIndex:i]UTF8String];
}
@catch (...)
{
return "";
}
}
Some time ago, Will started a new job- a four month contract to take an old, ugly DOS application and turn it into a new, shiny VisualBasic 6 application. "And," the new boss explained, "the new program is almost done anyway. It's just that the last guy left, so we need someone to take it over the finish line."
A key feature was that it needed to be able to fetch PDF files stored on a shared network drive. The order numbers were serialized, but the PDFs themselves were organized by year, creating file paths like I:\ORDLOG\2007\172.pdf. Now, in this particular block of code, one had access to both the ordnum and the ordyear, so constructing this path could be a trivial exercise. The previous developer did not take the trivial path, though.