Years ago, Aleshia W started a job in a VB.Net shop. There's a lot I could say about those kinds of environments, but I'd really just be padding out the article, so let's just get right to the code- which pads out a Year string.

Protected Function YearPadText(ByVal val As String) As String
    Dim valLen As Integer
    valLen = val.Len

    Select Case valLen
        Case 1
            val = val + "              "
        Case 2
            val = val + "             "
        Case 3
            val = val + "            "
        Case 4
            val = val + "           "
        Case 5
            val = val + "          "
        Case 6
            val = val + "         "
        Case 7
            val = val + "        "
        Case 8
            val = val + "       "
        Case 9
            val = val + "      "
        Case 10
            val = val + "     "
        Case 11
            val = val + "    "
        Case 12
            val = val + "   "
        Case 13
            val = val + "  "
        Case 14
            val = val + " "
    End Select
    Return val
End Function

Last week, we took a look at a hash array anti-pattern in JSON. This week, we get to see a Python version of that idea, with extra bonus quirks, from an anonymous submitter.

In this specific case, the code needed to handle CSV files. The order of the columns absolutely matters, and thus the developer needed to make sure that they always handled columns in the correct order. This led to code like this:

Validating email addresses according to the actual email specification is more complicated than you usually think. Most homebrew validation tends to just get something that's relatively close, because hitting all the rules requires some fancy regex work. And honestly, for most applications, "pretty close to correct" is probably fine. If you actually care about collecting valid email addresses, you'll need to actually send mail to the address and have the user confirm receipt to "prove" that the email address is real, valid, and actually accessible.

Still, some "close enough" solutions are better than others. Jon found this C# code:

Validation highlights the evolution of a programmer as they gain experience. A novice programmer, when given a validation problem, will tend to treat the string like an array or use substrings and attempt to verify that the input is the correct format. A more experienced programmer is going to break out the regexes. A very experienced programmer is going to just find a library or built-in method that does it, because there are better ways to use your time.

Andrea provides a rare example of a developer on the cusp between regexes and built-in methods.

There's a lot of room for disagreement in technology, but there's one universal, unchangeable truth: Oracle is the worst. But a second truth is that there's nothing so bad a programmer can't make it worse.

Someone at Ben's company needed to take data from a database and write it to a file. That file needed to have some specific formatting. So they used the best possible tool for the job: a PL/SQL stored procedure.

When Arbuzo joined a new team, they helpfully provided him some sample code to show him how to interact with their JSON API. It was all pretty standard-looking stuff. If, for example, they fetched a Customer object, it would have some fields about the customer, and an array containing links to orders that customer had made. One of the samples helpfully showed iterating across the orders array:

let i = 1;
while(cust.orders[i]) {
    //do stuff with cust.orders[i]
    i++;
}