• Tinkle (unregistered)

    Not quite what it is doing.

    new Guid() will create a guid with all zeros.

    To create a guid you use the method Guid.NewGuid().

    Still a WTF, just more in the framework than this code.

  • guest (unregistered)

    new Guid() in C# actually return 00000000-0000-0000-0000-000000000000 (this is also accessible via Guid.Empty). To create a random Guid you have to call Guid.NewGuid(). I'm guessing this is to match behavior with other value types, since those also default to the, well, default value when instantiated. So this code actually checks if the given Guid is non 0.

  • Jaloopa (unregistered)

    new Guid() in C# returns an empty Guid {00000000-0000-0000-0000-000000000000}.

    Guid.NewGuid() returns a random Guid.

    This is a weird way of checking the provided Guid is set to something

  • Prime Mover (unregistered)

    Comment held for moderation.

  • c# developer (unregistered)

    Actually, the code does something completely different: new Guid() created a specific Guid composed only of zeros (00000000-0000-0000-0000-000000000000), so the code is checking it that specific 0 guid has been passed in.

    If you want a new random guid you need to use Guid.NewGuid()

  • New Guy (unregistered)

    Sounds to me like the coworker is a new guy...d.

    And almost certainly unique. Perhaps a bit null as well.

  • L (unregistered)

    (probably the 7 comments held for moderation are saying that same thing -- TRWTF #1)

    actually new Guid() in c# doesn't randomly generates one because a value type default constructor is always generated by the compiler as to fill the memory with zero, therefore yielding the 00000000-0000-0000-0000-000000000000 Guid -- TRWTF #2

  • Anonymouse (unregistered)

    new Guid() actually returns the same as the static Guid.Empty field, an empty GUID (all zeroes). If you'd want a new random Guid, you'd use Guid.NewGuid().

    This check could be rewritten as if (objectId != Guid.Empty).

  • (nodebb)

    Isn't the "non-nullable" support in C# an optional feature?

  • (nodebb) in reply to Anonymouse

    new Guid() actually returns the same as the static Guid.Empty field

    True, but it's mostly by coincidence. Guid is a "value" type, and the parameterless constructor of such a type initialises it (and by implication its members) to default values, which (because the members are all value types) means zero.

    It's worth noting that the Microsoft documentation doesn't mention the parameterless constructor at all.

  • (nodebb) in reply to R3D3

    More like the other way around - nullability is optional for "value" types.

  • (nodebb)

    The first thing to note here is that Guid objects in C# are non-nullable value types. That is to say, objectId cannot possibly be null.

    If objectId is declared as Guid? objectId, then yes, it can be null.

  • LCrawford (unregistered)

    There are many duplicates, but isn't this code simply a valid but awkward way to ensure that the GUID was generated by Guid.NewGuid() rather than a misused 'new Guid()'?

  • (nodebb)

    TRWTF here is that Remy's interpretation of this code is wrong in at least two ways 😆

    • We're missing context, so we don't know how objectId is declared. It could be a Guid? (a.k.a. Nullable<Guid>), in which case it could be null
    • new Guid() isn't the same as Guid.NewGuid(). The default constructor of a value type just creates an all-zero instance of the type, so 00000000-0000-0000-0000-000000000000 in this case. (although in recent versions of C#, it's possible to create explicit default constructors on structs, making the existing Guid default constructor even more confusing...)
  • (nodebb)

    Actually, I think you'll find that new Guid() returns a GUID with all bits set to zero....

    ... oh wait..... frist! No, dammit.

  • TheCPUWizard (unregistered)

    is objectId is declared as Object?

    SOO many things wrong with this article(not the submitter), that this article) rather than any submission may win the WTF of the week award....

  • ricecake (unregistered)

    I don't know if anyone's mentioned it yet, but new Guid() returns a Guid with all zeros, and you have to use Guid.NewGuid() to get a randomly generated value.

  • Brian (unregistered) in reply to R3D3

    There is an optional feature for explicitly nullable reference types. I love it, it's great for avoiding those pesky null-reference errors, but it's only syntactic sugar. There's nothing at build or run time to prevent you from assigning null to a non-nullable reference. As mentioned already, value types are never nullable, unless you wrap them with a Nullable<T> (or the '?' abbreviation).

  • (nodebb) in reply to TheCPUWizard

    That was exactly my thought. Since objectId is of type object, the developer couldn't figure out how to compare it to Guid.Empty (obviously, using something like object.Equals(objectId, Guid.Empty)), and went with the ToString approach. The article is a much bigger WTF than the code itself.

  • (nodebb)

    I'm pretty sure you get at least a compiler warning when trying to compare value types to null. So objectId is probably of type object (or if it's really WTF, dynamic).

    So the real WTF is the developer is not using types and/or casting properly, also doesn't know about Guid.Empty.

    Addendum 2023-08-16 11:03: On the other hand, if objectId is a Guid? (that is, a nullable Guid), then the comparison to null is fine. But then the developer could have compared it to a new Guid easily so this is probably not the case.

  • (nodebb)

    Suppose ObjectID is a Guid? At that point the code makes sense other than it should be compared to Guid.Empty rather than new Guid(). This is testing for a null or default case, akin to String.IsNullOrEmpty();

  • anonymous (unregistered) in reply to Prime Mover

    Comment held for moderation.

  • (nodebb) in reply to anonymous

    Comment held for moderation.

    Is this some sort of protest against / joke about the long list of "held for moderation" comments yesterday? After all, those should have a gray background.

  • (nodebb) in reply to R3D3

    Value types (struct) have always been non-nullable (because they are stack values), since 2.0 there is a generic type struct Nullable<T> (also a value type), which is basically T plus a boolean if T should be considered null. There's a lot magic actually happening on a CTS level so that nullable value types behave very similar to reference types.

    Reference types (class) on the other hand are always nullable (because they live on the heap and are allocated, so basically they are type safe pointers and a zero pointer is considered invalid), which makes them compared to value types super expensive especially when it comes to allocations (but also when they get released). Since .net 5 there is an option to opt-into the non-nullable reference type feature, which dictates syntactically that reference should be treated by the compiler as non-nullable. However there is less direct support on a CTS level, so there's a lot of attributes required even for a common application developer to make the feature work correctly (for example when you implement the Try-Parse pattern for reference types).

  • (nodebb) in reply to Steve_The_Cynic

    All value types have a default constructor which initializes structs to binary zeros.

Leave a comment on “Random Comparison”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article