• (nodebb)

    Then we delete 22 characters from the Base64 encoded GUID.

    That's wrong. sb.Remove(22, 2) doesn't remove 22 characters; It deletes 2 starting at index 22. My guess is: the string ended up 24 chars long, and instead of using a Substring call, they use Remove because they needed complexity.

    Addendum 2023-04-10 07:27: Yep. Convert.ToBase64String(bytes) returns a 24 char long string. The StringBuilder usage is, also, arguably useless, but it helps improve the complexity, which is nice.

  • (nodebb)

    The only reason that they are making it length 22 is because base64 might end in = or even == which is presumably seriously forbidden for this use case.

    bGlnaHQgd29yaw==
  • LZ79LRU (unregistered)

    I believe this is C#. In which case the logic behind the removal of the last 2 characters is right in the language specification.

    Convert.ToBase64String(bytes) always returns a 24 character long string. But the last two characters are just padding for which it uses the valueless character '='. Which is to say your GUID is all in the first 22 characters and the last two are just padding which can be safely removed. And doing so is pretty standard practice when dealing with GUIDs if you are short on space.

  • WTFGuy (unregistered)

    @LZ79LRU: I'm not sure how one can be "short of space" to store this equals-trimmed-almost-Base64 data but not also short of space to hold the many more bytes of code needed to mangle it. Plus of course if you have a need to round-trip the Base64 encoded value back to the byte array back to the GUID, scraping the trailing "==" off needs to be reversed at the other end too. I'm doubting this is quite as standard as you say, but I don't work where you do.

    Said another way: Not sure that gains much in any non-insane situation. Also of course insane-but-unchangeable situations abound in our biz, but we ought not be making more of them if we can avoid it.

    Agree w the submitter: given the absolutely wacky "requirements" (which may be illusory, but that's an upstream error) this is clear code implemented in a straightforward readable way. It's insanity, but clear crystalline insanity. That's the richest kind.

  • Barry Margolin (github)

    "no reason why the method can't be static". Someone remembered that static variables make a function non-reentrant, and they thought this applied to static methods.

  • Anon (unregistered)

    Those replacements look very suspiciously like it's trying to avoid algebraic operations that might be processed by the template engine...

  • LZ79LRU (unregistered) in reply to WTFGuy

    The usual culprit there are retarded outside API's that have a character limit. They also happen to be the primary reason for converting GUID's to base64 to begin with as it shrinks them to 24 (potentially 22) characters instead of 36.

    Guess how I know.

  • LZ79LRU (unregistered)

    Could be worse though. In one of my previous jobs years ago I had to fix a bug relating to frequent GUID collisions. Turns out that there was a 24 character limit for a message field by an outside API. And since the programmer before me had newer heard of ToBase64 he just shortened the GUID by cutting off the last 12 digits.

  • (nodebb) in reply to colejohnson66

    SubString creates a new string instance which has the chance of automatically becoming interned, which is bad. So that one is actually the correct choice, while everything else including turning the UUID into a string, is bad.

  • (nodebb)

    The other potential WTF isn't in the code itself, of course.

    If the ID generated by this mess if sent to the client as a form-field ID in HTML, it will absolutely break browser form-filling methods.

    Well, unless I've missed something somewhere, which is possible.

  • (nodebb)

    Another WTF is making this a property rather than a method

  • (nodebb) in reply to MaxiTB

    SubString creates a new string instance which has the chance of automatically becoming interned

    WTF? Interning is something that shouldn't be done automatically (except for constants in the original source code) precisely because it can leak memory in very-awkward-to-recover ways. (That isn't to say that an already-interned string couldn't be substituted, but you shouldn't be interning anything new without direct programmer say-so.) This sort of thing has been well known for literally decades; I remember having to watch out for it when coding in the 1990s.

  • Frederic Jones (unregistered)
    Comment held for moderation.
  • (nodebb) in reply to WTFGuy

    Plus of course if you have a need to round-trip the Base64 encoded value back to the byte array back to the GUID,

    Well you don't. You use the GUID converted to a 22 character string as the id. No need to ever convert it back to a fully written out GUID.

Leave a comment on “Uniquier”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article