Vaut-il même la peine de vérifier si Guid.NewGuid () est Guid.Empty?

Dans l'un des projets sur lesquels je travaille, le schéma suivant est observé assez régulièrement:

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

Bien que je comprenne qu'un aa GUID n'est pas garanti d'être unique et que, selon la documentation MSDN, un GUID généré peut être nul , est-ce une considération pratique qui vaut vraiment la peine d'envoyer des tests de cycles à la fois dans le sens du calcul et en termes de temps de développement pour les développeurs ?

Je dirais que cela ne vaut pas la peine de vérifier Guid.Empty. Les documents pour Guid.NewGuid pour une raison quelconque mentionnent que

La probabilité que la valeur du nouveau Guid soit entièrement nulle ou égale à tout autre Guid est très faible.

Guid.NewGuid est un wrapper pour l'API Win32 CoCreateGuid , qui ne fait aucune mention du retour de tous les zéros.

Raymond Chen va plus loin , suggérant que

aucune implémentation valide de CoCreateGuid ne peut générer GUID_NULL

Donc, non, je ne m'en inquiéterais pas. Je ne devine pas pourquoi les documents Guid.NewGuid le mentionnent même.

Si vous trouvez que Guid.NewGuid() == Guid.Emptyvous avez gagné la loterie la plus difficile au monde. Ne vous embêtez pas avec l'unicité ou la vérification des collisions. Ne pas avoir à faire est ce que GUIDs sont pour . Je vais vous épargner les maths, c'est partout sur le web.

De plus, les guides Windows ont toujours un "chiffre" égal à 4. Les guides sont structurés.

L'extrait de code que vous avez publié ressemble à un développeur qui a oublié d'initialiser une Guidvariable et l'a trouvée Guid.Empty. Il a identifié à tort Guid.NewGuid()que la cause. Maintenant, il y croira à jamais superstitieusement.

En tout cas, ce n'est pas la bonne question à poser. Je suis sûr que votre code ne dépend pas seulement de ne jamais dessiner Guid.Emptymais aussi de l'unicité. Cette whileboucle n'impose pas l'unicité. Les guides sont là pour produire une valeur unique sans coordination. C'est leur cas d'utilisation.

Regardez le code source de la Guid.NewGuidméthode :

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

Voir le contrat de code? La Guid.NewGuidméthode ne donne jamais un GUID vide.

Si vous allez vérifier le GUID par rapport au GUID zéro, vous devez également, par la même logique, faire preuve de diligence raisonnable en le comparant à tous les autres GUID de votre application (car la probabilité d'obtenir un zéro devrait être la même que la probabilité de obtenir tout autre GUID dans votre application *). Vous devez le faire pour prouver que l'axiome sous lequel vous agissez est que ce GUID sera unique (qui est en fait le même axiome que le test vs 0).

Évidemment, cela est absurde.

TLDR; Si vous pouvez faire confiance à NewGuid () pour produire des résultats uniques, vous pouvez également lui faire confiance pour ne produire aucun GUID connu unique.

* Ce n'est en fait pas la même probabilité que les GUID .NET correspondent toujours aux éléments suivants, {________-____-4___-____-____________}donc NewGuid ne générera JAMAIS un guid zéro

Juste pour le plaisir, j'ai suggéré une amélioration des documents ici: http://feedback.msdn.com/forums/257782-msdn-feature-suggestions/suggestions/7143498-fix-documentation-for-newguid