UUIDs, aka GUIDs are, well… unique. Unique identifiers. It’s right there in the name.
Active Directory needs to identify things. Thus, it uses GUIDs. “Omni’s” co-worker got this far, but then ran into a problem. If you print a GUID from AD, it looks like this: “35918bc9196d40ea9779889d79b753f0”, but if you print it from C#, it looks like this: “35918bc9–196d–40ea–9779–889d79b753f0”. Whatever is a programmer to do when dealing with these radically incompotible formats?
private void GetUsers(Guid guid)
{
byte[] bytes = guid.ToByteArray();
string native = BitConverter.ToString(bytes).Replace("-", string.Empty).ToLower();
…
}
Okay, step one- turn the GUID into an array of 16 bytes. That makes sense. There’s no dashes in an array. Then we feed it into something called BitConverter
. Now, I don’t know what BitConverter does, so I can only guess, and there are two likely things:
- It turns an array of bytes into a string
- It turns an array of bytes into a string AND FOR SOME REASON INSERTS DASHES
Once we’ve got the array of bytes back into a string, we can replace the dashes (which either are not there, or were inserted by BitConverter
), and then convert it into lowercase, just in case hexidecimal has suddenly become case sensitive.
Of course, all of this is unnecessary. The GUID datatype in .NET overloads ToString
. guid.ToString("N")
would return “35918bc9196d40ea9779889d79b753f0”, just like our developer wanted.
This is at least a case of a developer not checking the documentation or lacking the instinct to ask, “Wait, does ToString
have any overloads?” That, however, is not TRWTF. TRWTF is stringly typed data. GUIDs are not strings. They are numbers. We render them as strings for readability. We should not process them as strings. We should not pass them around as strings. The string representation of a GUID should not be relevant to a program.