Query strings are, as the name implies, strings. Now, pretty much any web application framework is going to give you convenient access to the query string as a dictionary or map, because at the end of the day, it is just key/value pairs.

But what's the fun in that? Glen's application needed to handle query strings in the form: zones=[pnw,apac]&account_id=55. Now, enclosing the list in square brackets is a little odd, but actually makes sense when you see how they parse this:

act.zones = account_values.Substring(account_values.IndexOf("zones=") + 
    "zones=".Length + 1, (
        account_values.IndexOf("]", 
            account_values.IndexOf("zones=") + "zones=".Length + 1) - 
            (account_values.IndexOf("zones=") + "zones=".Length + 1)
    )
).Split(',');

Oh, wait, I'm sorry. Did I say "made sense"? I meant "you can see why they did it, but it's still not a good reason."

This was originally on one line, line-breaks were added to try and make it more readable, and likely failed to do so.

This code takes a substring, first by finding where zones= appears in the string, then skipping past its length + 1- which skips the first square bracket. Then it grabs until the ]. But to find the correct ], we have another stack of IndexOf calls to make sure that we start searching after zones=. Once we've grabbed that whole section, we can finally Split on commas, and have our lovely list.

Now, unless area names can contain an &, which I suppose is possible, there's no reason to do the [] wrapper, as we could just grab the index of the & instead. While we're at it, we could also not write this as a one-liner, and use some variables to cut down on the IndexOf calls. Of course, there's no reason to do any of this, so maybe instead of thinking up a better version, I should just let it be.