• Prime Mover (unregistered)

    Ridiculous! Throw it all away and replace it with a bubble sort, that's what I'd do.

  • X (unregistered) in reply to Prime Mover

    At least use insertion or selection sort. That's still bad (for large lists) but a constant factor faster than bubble sort.

  • LCrawford (unregistered)

    Lambda-think wasn't a thing back in the COM <> .NET early interop days.

    The result of this sort is interesting, where customer ID 100 is less than customer ID 2.

  • (author) in reply to LCrawford

    Sure, but comparator classes and delegates absolutely were. And I was still doing interop all the way up into the 3.5 days, so lambdas still overlap.

    (Yes, it sucked)

  • (nodebb)

    All you have to do is include the iComparable interface and implement CompareTo() and then you can sort the list of Customers. I guess even doing that would be too much learning/work.

  • WTFGuy (unregistered)

    I swear about 25% of the dev community stopped learning anything about algorithms or their language once they were half-assed familiar with arrays, for loops, and strings.

    If you can't build it out of those 3 things, it must be impossible. Sheesh!

  • Vilx- (unregistered)
    <!-- Easy Reader Version: I'm out of sorts -->

    Zero sorts to give, huh?

  • van Dartel (unregistered)

    I agree there's room for improvements. Here's my top 5 in arbitrary order and varying levels of seriousness:

    1. orderCustomerAZ sorts by IDs, which suggests than IDs carry more information than what I'd expect (i.e. just some anonymous UIDs)
    2. The function name is not politically correct not future proof (what if IDs are or will be in Thai?)
    3. The cloning of objects is highly suspicious (I wouldn't normally expect that reordering a list of X objects returns a list of completely different objects)
    4. Normalizing sorting into a quadratic algorithm? (I'm all for consistency, but I am not up to that god-level)
    5. The exception handling is exceptional (when will we see the introduction of "class BadCodeDetected extends FatalError"?)
  • Anon (unregistered)

    I see no reason to assume ID is numeric.

  • (nodebb) in reply to Vilx-
    <!-- Easy Reader Version: I'm out of sorts -->

    Zero sorts to give, huh?

    Probably just a bit annoyed and upset.

    https://en.wiktionary.org/wiki/out_of_sorts

  • (nodebb) in reply to LCrawford

    Lambda-think wasn't a thing back in the COM <> .NET early interop days.

    This doesn't require Lambda-think to make it sane. Not saying that lambdas aren't the best choice, but there are non-lambda solutions that don't make you want to poke your eyes out.

    private int SortByID(Customer c1, Customer c2)
    {
        return c1ID.CompareTo(c2.ID);
    }
    
    CustomerList.Sort(SortByID);
    
  • van Dartel (unregistered) in reply to Prime Mover

    Surely no programmer who wants to be productive likes nested loops dealing with two indices independently (like in Bubble-sort). That's why I prefer this algorithm (not named out of modesty): check if the list is in order; if not: randomly choose 2 neighbors, swap them and repeat. It uses only one index, only one loop, and is even adaptive to perfectly sorted inputs.

    PS: if anybody dares to suggest there's a 2nd, hidden loop I will point out the fact that "repeat" is actually a "goto", so that doesn't count.

  • (nodebb)

    Everyone has also assumed that the ID is unique in the list. If not, Items will be lost after the sort (and others duplicated) since it only considers the first match.

  • van Dartel (unregistered) in reply to Auction_God

    You're absolutely right, and the main cause is that we've all been indoctrinated to use variable names that reflect the contents/meaning/properties/etc. of their values. Consequently, almost nobody realized that IDs might not be unique and that's a worrying thought. Perhaps it's time for a new dogma: I propose that from now on all variables, functions, procedures etc. are to be named x0, x1, x2, ... Just to not upset anybody I'll leave name spaces out of this (for now).

  • (nodebb)

    Reminds me of a function I wrote (also in VB.NET) to sort four arrays that contained related data (like, array 1 was a list of person IDs, array 2 was a list of the names of those people in the same order, and so on). So rather than replacing the four arrays with something sensible, like a single array of some sort of class that contains four properties, I went ahead and wrote a function to sort the arrays in place. I don't remember the details but I remember it took four generic type parameters, one for each array, and used tuples to couple the items together. Why did I do this? I honestly don't remember, my best guess is that refactoring all the code that generated the arrays would be too error prone. But at least it was faster than the old array sorting code. It was a bubble sort. I kid you not.

  • Charlie (unregistered)

    The .Clear() at the end followed immediately by an assignment is a real gem. He's overwriting the original List reference anyway, so why clear it. It won't make any difference to GC unless it's triggered between those two statements, because .Clear() just blanks the internal array without making it any smaller. I suppose it would have been worse if he'd then done an AddRange() instead (that's basically memcpy).

  • Some Ed (unregistered) in reply to van Dartel

    But if you don't name your spaces, how do you tell subroutines whose names are identical except for the name of the spaces embedded within them?

    Disclaimer: this response was brought to you by a nightmare I had some years back, rather than any actual code I've seen in real life. I am delighted to say that I can't accurately depict the sort of attrocity I'm talking about, because we do not even have IDEs that can render that insanity.

  • Your Name (unregistered) in reply to LCrawford

    Standard Linux style sort gives the same result.

Leave a comment on “When All You Have Is .Sort, Every Problem Looks Like a List(of String)”

Log In or post as a guest

Replying to comment #:

« Return to Article