Lohnt es sich überhaupt zu überprüfen, ob Guid.NewGuid () Guid.Empty ist?

In einem der Projekte, an denen ich arbeite, sieht man ziemlich regelmäßig folgendes Muster:

var guid = Guid.NewGuid().ToString();
while (guid == Guid.Empty.ToString())
{
    guid = Guid.NewGuid().ToString();
}

Obwohl ich verstehe, dass eine GUID nicht garantiert eindeutig ist und gemäß der MSDN-Dokumentation eine generierte GUID Null sein kann , ist dies eine praktische Überlegung, die es tatsächlich wert ist, Zyklustests zu senden, sowohl im rechnerischen Sinne als auch in Bezug auf die Entwicklerzeit, die darüber nachdenkt ?

Ich würde vorschlagen, dass es sich nicht lohnt, nach Guid.Empty zu suchen. Die Dokumente für Guid.NewGuid erwähnen das aus irgendeinem Grund

Die Wahrscheinlichkeit, dass der Wert der neuen Guid alle Nullen oder gleich einer anderen Guid ist, ist sehr gering.

Guid.NewGuid ist ein Wrapper für die Win32-API CoCreateGuid , in dem die Rückgabe aller Nullen nicht erwähnt wird.

Raymond Chen geht noch weiter und schlägt dies vor

Keine gültige Implementierung von CoCreateGuid kann GUID_NULL generieren

Also, nein, ich würde mir darüber keine Sorgen machen. Ich werde nicht erraten, warum die Guid.NewGuid-Dokumente es überhaupt erwähnen.

Wenn Sie feststellen, dass Guid.NewGuid() == Guid.EmptySie die härteste Lotterie der Welt gewonnen haben. Kümmern Sie sich nicht um Eindeutigkeits- oder Kollisionsprüfungen. Nicht mit zu tun , das ist , was guids sind für . Ich werde dir die Mathematik ersparen, es ist überall im Web.

Außerdem haben Windows-Guids immer eine "Ziffer" gleich 4. Guids haben eine gewisse Struktur.

Das von Ihnen gepostete Code-Snippet sieht so aus, als hätte ein Entwickler vergessen, eine GuidVariable zu initialisieren , und festgestellt, dass dies der Fall ist Guid.Empty. Er identifizierte fälschlicherweise Guid.NewGuid()als die Ursache. Jetzt wird er für immer abergläubisch daran glauben.

In jedem Fall ist dies die falsche Frage. Ich bin mir sicher, dass Ihr Code nicht nur vom Zeichnen abhängt, Guid.Emptysondern auch von der Eindeutigkeit. Diese whileSchleife erzwingt keine Eindeutigkeit. Guids sind dazu da, ohne Koordination einen einzigartigen Wert zu produzieren . Das ist ihr Anwendungsfall.

Schauen Sie sich den Quellcode der Guid.NewGuidMethode an :

public static Guid NewGuid() {
    Contract.Ensures(Contract.Result<Guid>() != Guid.Empty);
    ...
}

Sehen Sie den Code Vertrag? Die Guid.NewGuidMethode liefert niemals eine leere GUID.

Wenn Sie die GUID mit der GUID Null vergleichen möchten, müssen Sie nach der gleichen Logik auch die GUID mit der gebotenen Sorgfalt mit allen anderen GUIDs in Ihrer Anwendung vergleichen (da die Wahrscheinlichkeit, eine Null zu erhalten, mit der Wahrscheinlichkeit von identisch sein sollte Beliebige andere GUID in Ihrer App erhalten *). Sie müssen dies tun, um zu beweisen, dass das Axiom, nach dem Sie handeln, die Eindeutigkeit dieser GUID ist (was eigentlich dasselbe Axiom ist wie das Testen gegen 0).

Offensichtlich ist das absurd.

TLDR;Wenn Sie sich darauf verlassen können, dass NewGuid () eindeutige Ergebnisse liefert, können Sie sich auch darauf verlassen, dass es keine einzige bekannte GUID liefert.

* Es ist eigentlich nicht die gleiche Wahrscheinlichkeit wie .NET-GUIDs passen immer die folgenden {________-____-4___-____-____________} sodass NewGuid NIEMALS eine Null-GUID generiert

Aus Spaß schlug ich hier eine Verbesserung der Dokumentation vor: http://feedback.msdn.com/forums/257782-msdn-feature-suggestions/suggestions/7143498-fix-documentation-for-newguid