Cicely (previously) returned to the codebase which was providing annoyances last time.
This time, the code is meant for constructing objects based on a URL pattern. Specifically, the URL might have a format like api/resource/{id}
. Looking at one of the constructors, though, it didn’t want an ID, it wanted an array of them. Cicely wasn’t passing multiple IDs off the URL, and wasn’t clear, from the documentation, how it worked, how you supplied those IDs, or frankly, what they were used for. Digging into the C# code made it clear, but still raised some additional questions.
int[] ids = Request.FormOrQuerystring("ids").EnsureNotNull().Split(",").
Select(item => item.ToInt32()).Concat(new int[] { id }).ToArray();
Whitespace added for readability, the original was on one line.
This is one of those cases where the code isn’t precisely bad, or wrong. At worst, it’s inefficient with all the LINQs and new arrays. It’s just… why would you do this this way?
At its core, we check the request for an ids
property. EnsureNotNull()
guarantees that we’ll see a value, whether there is one or not, we Split
it on commas, project the text into Int32
using Select
… and then concatenate a one element array onto the end, containing our id
off the URL.
Perhaps someone wanted to avoid branching logic (because it’s potentially hard to debug) or maybe wanted some “functional purity” in their programming. Maybe they were just trying to see how much they could cram into a single line of code? Regardless, Cicely considers it a “most imaginative way to set a default value”. It’s certainly clever, I’ll give it that.