Ben ran into some misbehaving C# code- handling users was not doing what it was supposed to do, and when "what it's supposed to do" is "prevent users from seeing content owned by other users without permission", that's a bad thing.

The code Ben found wasn't the cause of the bug, but it ended up wasting a bunch of his time as he tried to understand why it existed.

Ah, the joy of comments. Good comments can illuminate complicated code, explain a programmer's reasoning, or even just do their best to absolve a burned out programmer of their sins. "Yes, it's bad, but it works."

Then there's this comment, sent to us by Mark B. This is from a configuration file format, "helpfully" explaining what the flag does.

Today, Morpheus sends us a SQL injection vulnerability. But it's a peculiar version that only uses parameters. Let's start with the bit that looks normal:

    strStrBuilder.Append(" update sometable set ")
    strStrBuilder.Append(" SOMECOLUMN = :p_somevalue, ")
    strStrBuilder.Append(" rowuserid = :p_userid, ")
    strStrBuilder.Append(" rowtaskid = :p_taskid ")
    strStrBuilder.Append(" where id = :p_id")
    strSQL = strStrBuilder.ToString

One of the most powerful features of using exceptions for error handling is that they let you create your own exceptions, and thus accurately describe the family of exceptional situations your code could generate. On the flip side, some developers over-specialize, creating custom exceptions for every different place an out-of-range error could happen, for example.

Then there's the code Nasch was debugging recently. The previous developer found a different way to create unique exceptions for every place an error might occur.

Way back when Microsoft added LINQ to .NET, the real selling point was lazy evaluation. You could do something like var x = someList.Skip(3).Where((x) => x > 3).Take(5) and nothing would actually happen until you attempted to interact with the value of x. This can be especially great when interacting with a database, avoiding the round-trip until you actually need the data, and then only fetching the data which fulfills your request. If you understand what's happening, this can be pretty great.

If you understand. Which brings us to Simon, who has inherited a "particularly bad" code base. This particular system is for tracking attendance, and the pool of individuals being tracked is rather large, so someone wanted to make sure that they were processed in batches of no more than 30. This is how they accomplished that.

Visual Basic for Applications represents the core mistake of putting a full-featured programming environment on every desktop. That so much VBA code is bad is not remarkable- that any good code exists would be shocking.

We rarely cover VBA code, because most of it is written by a non-programmer who discovered they could solve real business problems in Microsoft Access. TRWTF is, in fact, how much of the world runs on an Access database stuffed into a network share somewhere. But there are organizations that hire developers and then shove them into writing VBA, which is what happened to Doug. This code comes from quite awhile ago.