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.
Ashton works for a large bank, on an application that handles millions of dollars of transactions. The previous developer left this behind, which has everyone on the team scratching their heads.
Sep 22if (BatchProcessor.ProcessBatch())
{
}
else
{
}
I used to work in a VB.Net shop. It wasn't my favorite place, but it gave me an appreciation for modern VisualBasic, instead of old VB6 (which I also had to work on).
Part of what made VB.Net better was that it had more sane defaults. By default it enabled Option Explicit (require variables to be declared before use), and Option Strict (error on any narrowing conversions between data-types). One of its biggest weaknesses, however, was that you could turn those features off, something which was frequently done to make old-style VB6 code more compatible with VB.Net. Arguably, the biggest WTF was that Microsoft promised an "easy" path to upgrade VB6 code to VB.Net, through a mix of compatibility libraries and conversion tools that didn't work.
The transition from Python 2 to Python 3 has been a long running challenge. Arguably, too long running, but those are the challenges when you introduce breaking changes into a widely used language.
Now, one of those breaking changes was around string handling and encoding- Unicode versus ASCII. This meant that, if you wanted code to run on both versions of Python, you'd need to check which version you were on to handle encodings properly.
We've all seen documentation blocks like this:
/**
* Get the value of instructions
*
* @return string|null
*/
public function getInstructions()
{
return $this->instructions;
}
Andrew had to touch some Pascal code. Yes, really. He writes: "I came across this section of code today and really wanted to find out who wrote it. Then I really wanted to find out who added the comment."
{ Ugly code follows, a loop would be nice }
{ Seller #1 }
if not EOF then
begin
lsSName := FieldByName('txtname').AsString;
if Length(FieldByName('txtsname').AsString) > 0 then
begin
lsSName := Concat(lsSName,', ' + FieldByName('txtsname').AsString);
end;
Next;
sctevarS1Name.AsString := lsSName;
end
else
begin
Close;
Exit;
end; { else }
{ Seller #2 }
if not EOF then
begin
lsSName := FieldByName('txtname').AsString;
if Length(FieldByName('txtsname').AsString) > 0 then
begin
lsSName := Concat(lsSName,', ' + FieldByName('txtsname').AsString);
end;
Next;
sctevarS2Name.AsString := lsSName;
end
else
begin
Close;
Exit;
end; { else }
{ Seller #3 }
if not EOF then
begin
lsSName := FieldByName('txtname').AsString;
if Length(FieldByName('txtsname').AsString) > 0 then
begin
lsSName := Concat(lsSName,', ' + FieldByName('txtsname').AsString);
end;
Next;
sctevarS3Name.AsString := lsSName;
end
else
begin
Close;
Exit;
end; { else }
{ Seller #4 }
if not EOF then
begin
lsSName := FieldByName('txtname').AsString;
if Length(FieldByName('txtsname').AsString) > 0 then
begin
lsSName := Concat(lsSName,', ' + FieldByName('txtsname').AsString);
end;
Next;
sctevarS4Name.AsString := lsSName;
end
else
begin
Close;
Exit;
end; { else }
Doug's co-workers were creating a database to manage a set of custom application services and their associated metadata. So one of them threw together this table:
create table applications (
name varchar(20) primary key,
attribute varchar(20) not null,
listen_port integer not null unique,
admin_user varchar(20) not null
)
Nyegomi supports a system with a load of actor objects tied to a bus, and supporting huge numbers of concurrent users. Once per second, the server looks at all the active objects and calls their update method, which gives them a chance to do vital housekeeping. Many of the objects may spin up background threads during that time.
Like a lot of threading code, this leads to loads of problems in the wrong hands. Extra problematic in Python.
Let's say you wanted to express the difference between two numbers as a percentage of the first number. And then let's say that you have no idea how to properly handle a situation where that first number is zero.
In that situation, you might end up with C code much like what Gaetan found.
Juan M inherited some broken code. Upon investigation, the result turned out to be caused by a mix of assumptions.
The first assumption was in the way their users would interact with their scheduling system. Part of the assumption there was that they wouldn't try and schedule any events outside of the scope of a few human lifetimes. The other part of the assumption was that their serialization framework would have a consistent representation of datetimes that was reliably the number of seconds past the Unix epoch.
Rich was digging through some legacy PHP code, trying to track down where some apparently magical values were coming from. This involved tracing through function after function after function.
Here's a sampling of some of those functions:
Pedro inherited a PHP application, and the previous developer had some opinions about how to handle arguments to functions. This is the pattern they used everywhere:
public function concatName($firstName, $lastName) {
$names = array ($firstName, $lastName);
$fullName = 'Mr.' . $names[1] . ' ' . $name[2];
return $names[0] . ' ' . $names[1];
}
Many years ago, a Paula Bean type was hired to make a Perl-based website. It became the company's flagship product, at least briefly, until a better version of the product was ready. But early adopters adopted it, and thus it had to keep operating, because you can't throw a way a 800kLOC web application just because it's fragile and unmaintainable.
And then the site got hacked. So now, fixing everything becomes incredibly important, and the task fell to Erik. He needed to do a security audit and identify vulnerabilities. Alone. In a 800kLOC application of extremely questionable code quality. For bonus challenges, there is no testing environment available and no budget to stand one up- even if anyone knew exactly what actually needs to be in that environment, because there's a bunch of databases and packages and extra software and no one is entirely sure what the production environment is.
If there's one thing worse in code than magic numbers, it's magic strings. Sean inherited an antique Visual C++ application, and the previous developers were very careful to make sure every string was a named constant.
const char $$B[] = "$$B";
const char $$E[] = "$$E";
const char $$L[] = "$$L";
const char $$IN[] = "$$IN";
const char $$OUT[] = "$$OUT";
const char $CODE[] = "$CODE";
const char $ENDE[] = "$ENDE";
As a general rule of thumb, when you see a class called StringConverter you know something is going to be wrong in there. That's at least what Erik thought when examining a bug in a totally different section of string handling code that just happened to depend on StringConverter.
StringConverter might sound like some sort of utility belt class with a huge pile of methods in it, but no- it's only got two. So we should take a look at both.