Since we were discussing XML earlier this week, it's a good time to take a peek at this submission from Mark.

Before we get into it, though, we need to talk briefly about some different XML parsing philosophies. XML documents are frequently large and deeply nested trees, and once loaded into memory, consume a lot of it. So there are two methods we might use to parse XML. We might parse and load the entire DOM- having all of that expensive processing and memory usage. The advantage is that we have the whole structure in memory, and can quickly and efficiently navigate through it. The other option is to read it as a stream, and process it one node at a time. This is both faster and a lot gentler on memory, but it means you have forward-only access to the contents.

Frequent contributor Argle found some code written at his current company a "long time ago", but unfortunately in a galaxy far too close to our own.

If rsRecordSetD1T3("ItemState")<>"N" then
    Select Case rsRecordSetD1T3("ItemState")
    Case "R", "L"
        tally=tally+1	
    Case "B"
        tally=tally+2
    Case "N"
        tally=tally+0
    Case Else
        tally=tally+0
    End Select
    …
End If

Mark B sends us another sample from a big-ball-o-wtf.

Let's take a look at two variables. One variable is named taskDetail. The other variable is named binaryTaskDetail. You might ask yourself: what are the differences between these two?

While JSON's strength is its (relative) simplicity, XML's strength was always its power. Combined with an XML schema, you can create strongly typed documents with arbitrary data-types. For example, it's easy to define, oh, I don't know, a date time field in a way that isn't stringly typed.

Of course, that's what also creates its complexity. XML is big, and bloated, and expensive to parse. Which brings us back to the old days of SOAP- the Simple Object Access Protocol, essentially an XML remote procedure call. It was powerful, but complex, with lots of interlocking standards. With its Web Service Description Language (WSDL), the service could even be self documenting, laying out all the objects and fields you could interact with.

It's important to be prepared- but not too prepared. A common trap developers fall into is "premature abstraction"- trying to solve the general case of a problem when you only need to solve a very specific case.

Frequent contributor Argle sends us some very old BASIC code. The task was to convert this ancient language into C#.

Way back in late 2006, Cody inherited a Java application. Since launching in 2001, the application had been running in production without any notable problems. And then, one day, it suddenly started throwing out errors on some orders. And then, a little later, any time someone tried to place an order. This constituted a rather large issue, since processing new orders was vitally important for keeping the lights on.

The errors were validation errors, so Cody started by going to the line where the validation happened, and the exception was thrown: