Forums
Alice works with an XML-based RPC system. They send requests, it does a thing, and returns back a response, all surrounded in XML. The service sending the requests, however, doesn't use a well-established parsing library. The result is that, well, the code ends up here.
First, though, a bit about the data they expect to parse. It's verbose, but fairly straightforward:
Evan sent us 545 lines of PHP code from a file called spec_email.php. It appears to participate in sending an email, with a nice big pile of HTML in it. We're going to take it in a few chunks, because… choices were made.
It opens with this check, and a few variable declarations:
Alexander sends us this snippet, where we change our definition of truth to something which eschews concrete definitions and accepts that existence is ephemeral. Truth and false are just illusions we project onto a reality that is itself just an illusion. In the end, we are all nothing.
May 24 public enum Bit
{
None = -1,
False = 0,
True = 1
}
When interacting with RESTful web services, there's a depressingly common anti-pattern: always return status 200 OK, but embed a more meaningful status code in the body of the response. Frequently, the embedded status code is just the HTTP status code you should have returned in the first place.
This "fixes" situations where you have badly behaving clients that don't do proper error handling, but also breaks the entire point of doing REST.
If I'm being completely honest, I'm mildly anti-ORM. I'm not about to go on a rampage and suggest they should absolutely, never, ever, ever be used, but I think they tend to create a lot of problems. Instead of being a true mapping between our object model and our relational model, they're their own tool, with its own idosynchracies, and a lot of "magic" that conceals its actual operation. For simple applications, they're great, but once you start getting into something more complicated than basic CRUD operations, you're in for a world of hurt. And that's before someone makes a mistake with eager vs. lazy fetching.
Today's anonymous submission offers us a good example of another way the mismatch can go wrong between objects and relations.
Today's a day for a smorgasbord. We're going to start with a classic kind of bad code, from astephens:
pbUpdates.Value = int.Parse(Math.Truncate(percentage).ToString());
David's application has loads of unit tests. Many of the unit tests even go so far as to exhaustively test every combination of parameters. So seeing something like this is pretty common:
[Test]
[TestCase(false, false, false, false, false)]
[TestCase(false, false, false, false, true)]
[TestCase(false, false, false, true, false)]
[TestCase(false, false, false, true, true)]
[TestCase(false, false, true, false, false)]
[TestCase(false, false, true, false, true)]
[TestCase(false, false, true, true, false)]
[TestCase(false, false, true, true, true)]
[TestCase(false, true, false, false, false)]
[TestCase(false, true, false, false, true)]
[TestCase(false, true, false, true, false)]
[TestCase(false, true, false, true, true)]
[TestCase(false, true, true, false, false)]
[TestCase(false, true, true, false, true)]
[TestCase(false, true, true, true, false)]
[TestCase(false, true, true, true, true)]
[TestCase(true, false, false, false, false)]
[TestCase(true, false, false, false, true)]
[TestCase(true, false, false, true, false)]
[TestCase(true, false, false, true, true)]
[TestCase(true, false, true, false, false)]
[TestCase(true, false, true, false, true)]
[TestCase(true, false, true, true, false)]
[TestCase(true, false, true, true, true)]
[TestCase(true, true, false, false, false)]
[TestCase(true, true, false, false, true)]
[TestCase(true, true, false, true, false)]
[TestCase(true, true, false, true, true)]
[TestCase(true, true, true, false, false)]
[TestCase(true, true, true, false, true)]
[TestCase(true, true, true, true, false)]
[TestCase(true, true, true, true, true)]
public void UpdateClientSettingsTest(bool canCreateBeneficiary,
bool canCreatePayment, bool canCreateDeal,
bool canEditPlan, bool isPayrollEnabled)
{
}
Today, I'm honestly not sure that the WTF is in the code we're looking at. Jeff needed to support an older PHP application which used client side JavaScript heavily. This block was copy-pasted many times throughout the code base:
var ajaxRequest; // The variable that makes Ajax possible!
try{
// Opera 8.0+, Firefox, Safari
ajaxRequest = new XMLHttpRequest();
} catch (e){
// Internet Explorer Browsers
try{
ajaxRequest = new ActiveXObject("Msxml2.XMLHTTP");
} catch (e) {
try{
ajaxRequest = new ActiveXObject("Microsoft.XMLHTTP");
} catch (e){
try{
ajaxRequest = new ActiveXObject("Msxml2.XMLHTTP.4.0");
}
catch(e){
// Something went wrong
echo("Something Wrong. Please try again later!");
return false;
}
}
}
}
Kyle sends us a puzzler of bad code today. It appears in a "JSP-like" codebase- which Kyle provides no futher details on, but certainly hints at a serious WTF underpinning this code.
boolean loop = true;
while (loop) {
// fake loop to break out of
loop = false;
doesStuff();
moreStuff();
etc();
}
Ever since the DOS days, determining file type based on the three letter extension in its filename has been a common practice. I'd argue that it's not a good practice, but it's become so standard that it's hard to avoid. It's so common that pretty much any language in wide use has some sort of "get extension" method. C# is no exception.
Of course, having a convenient and commonly used helper method is no barrier to writing it yourself, and Andrew found this code in their application, which is meant to extract "png", or "jpg" as the extension.
When you get into the world of proprietary filesystems, things can get real weird. There are many a filesystem that doesn't support directories, still in use today. Or filesystems which only allocated chunks in multi-megabyte blocks, which means you end up wasting a lot of space if you have small files. Or filesystems where the largest file size is itself a handful of megabytes.
Dan was working on one such filesystem where, when you opened a file for writing, you could specify how many "fixed records" it needed to support. So, for example, if you wanted to open a file for writing, in binary mode, you might do this: open(pathToFile, "f4096wb"): support 4096 records, and open it for writing.
Many years ago, Tom supported a VB6 application. It was about 750,000 lines of code, split across far too many files, with no real organization to it. While the code was bad and awful, the organization problem was a universal issue for the application. It even infested the database.
This is some VB6 code for querying that database:
Many a time, we've seen a program reach out into the database for date times. It's annoying to see, but not entirely stupid- if you can't rely on your web servers having synchronized clocks, the centralized database may very well be the only place you can get a reliable date/time value from. This ends up meaning you get a lot of date formatting happening in the database, but again- if it's the only reliable clock, you can't do better.
Unless you aren't even looking at a clock. Mendel sends us this C#:
One of the nice things about Git is that it makes it very easy for us to learn the steps that went into a WTF. It doesn't mean it explains the WTF, as many are just inexplicable, but it's at least something.
Like this example, from Aoife.
Chilly inherited a VB .Net application which generates an "IDoc" file which is used to share data with SAP. That's TRWTF, but the code has some fun moments:
If ldCashOut < 0 Then 'CashOut
loE2WPB06002.vorzeichen = " "
Else
loE2WPB06002.vorzeichen = " "
End If
If liTRANSTYPE = 2 Then 'Refund is always Positive
loE2WPB06002.vorzeichen = "+"
End If
loE2WPB06002.summe = Math.Abs(ldCashOut).ToString 'CashOut
loE2WPB06002.zahlart = "PTCS" 'CashOut
loE2WPB06002.vorzeichen = "-" 'CashOut