Forums
Happy Friday to those who celebrate. Enjoy it while it lasts, because Greg L. has some bad news. "It was nice hanging out with all of you, but it looks like the Sun is scheduled to expire Sunday morning." It's worse than that: the laws of physics are being replaced.
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.
Not to be outdone by Michael R., another prolific participant styles himself The Beast In Black. A handful of his experiences follow here. [psst. Mr Black. Check out this explanation of a half-closed interval)
Buyer Beast bemoans "I knew that the global situation was bad, but when Amazon starts offering disdiscounts (or discountcounts, perhaps?) you know that the world is truly up the toilet without a paddle roll."
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;
}
}
}
}
One of our most dedicated readers, Michael R., is also one of our most dedicated contributors, sometimes sending us several submissions in a single day. We haven't featured all of them, but now we're making up for that. Today, it's wall-to-wall Michael, mostly food misadventures. Michael might tell you we've cooked the plot, but he can't prove it.
On leaving France (it's a long story), Michael was confused at the airport. "Yo Sushi at Charles de Gaulle Terminal, please make up your mind about what payment types you accept." I think this one is pretty clear; just because a sign says they accept one form of payment it doesn't mean they categorically reject all others. So if your card is on either sign, you're covered. I hope he got fed.
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:
I'm fresh out of snark this week, so I'm relying on the rest of you to carry the load for me. Tote that barge, etc.
First up is a timely comment from an anonymous reader: "Even Kronos admits their software is a pain."
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