Ouais, pour la sécurité, je ferais probablement:

if(array == null || array.Length == 0)

Vous pouvez utiliser .Length == 0 si la longueur est vide et le tableau existe, mais êtes-vous sûr que c'est pas nulle?

Vous pouvez utiliser

if (array == null || array.Length == 0)

Ou

if (!(array != null && array.Length >= 0))

REMARQUE!!!!! pour s'assurer que c# implémentera correctement le court-circuit; vous devez comparer cet objet avec NULL avant d'aller à la comparaison des enfants de l'objet.

C'est la meilleure façon. Veuillez noter que Array est un objet dans NET, vous devez donc vérifier la valeur null avant.

Comme d'autres l'ont déjà suggéré, il est probable que vous obteniez un NullReferenceException qui peut être évité en vérifiant d'abord si la référence est null. Cependant, vous devez vous demander si ce contrôle est réellement justifié. Le feriez-vous parce que la référence pourrait vraiment être null et qu'elle est {[1] } a une signification particulière dans votre code? Ou feriez-vous pour couvrir un bug? La nature de la question me porte à croire que ce serait la dernière. Dans ce cas vous devez vraiment examinez le code en profondeur et découvrez pourquoi cette référence n'a pas été initialisée correctement en premier lieu.

Jon Skeet a répondu correctement. Rappelez-vous simplement que l'ordre du test dans le "SI" est important. Vérifiez la valeur null avant la longueur. Je préfère aussi mettre le nul sur le côté gauche de l'égalité...juste une habitude que J'ai eue de Java qui a rendu le code plus efficace et rapide... Je ne pense pas que ce soit important dans beaucoup d'applications aujourd'hui, mais c'est une bonne pratique.

If(null == array || tableau.Longueur = = 0)

Votre test suggéré est correct, tant que le tableau est initialisé...

Martin.

If (tableau.Longueur > 0)

Vérifiez d'abord si le tableau est null afin d'éviter une exception de pointeur null

Logique dans n'importe quelle langue: si le tableau est null ou est vide :do ....

Voulez-vous dire vide ou nul, deux choses différentes,

Si le tableau est instancié mais vide, alors length est correct, s'il n'a pas été instancié alors test vs null

Si array est null, en essayant de derefrence array.Length va lancer une NullReferenceException. Si votre code considère null comme une valeur invalide pour array, vous devez le rejeter et blâmer l'appelant. Un tel modèle est de lancer ArgumentNullException:

void MyMethod(string[] array)
{
    if (array == null) throw new ArgumentNullException(nameof(array));

    if (array.Length > 0)
    {
        // Do something with array…
    }
}

Si vous voulez accepter un tableau null comme indication de ne pas faire quelque chose ou comme paramètre facultatif, vous pouvez simplement ne pas y accéder s'il est null:

void MyMethod(string[] array)
{
    if (array != null)
    {
        // Do something with array here…
    }
}

Si vous voulez éviter de toucher array quand il est null ou a une longueur nulle, alors vous pouvez vérifier les deux en même temps avec l'opérateur de coalescence null C#-6.

void MyMethod(string[] array)
{
    if (array?.Length > 0)
    {
        // Do something with array…
    }
}

Vérification De Longueur Superflue

Il semble étrange que vous traitiez le tableau vide comme un cas particulier. Dans de nombreux cas, si vous, par exemple, faites une boucle sur le tableau de toute façon, il n'est pas nécessaire de traiter le tableau vide comme un cas particulier. foreach (var elem in array) {«body»} sera tout simplement jamais exécuter «body» lorsque array.Length est 0. Si vous traitez array == null || array.Length == 0 spécialement pour, par exemple, améliorer les performances, vous pouvez envisager laisser un commentaire pour la postérité. Sinon, la vérification de Length == 0 semble superflue.

Un Code superflu rend la compréhension d'un programme plus difficile car les personnes qui lisent le code supposent probablement que chaque ligne est nécessaire pour résoudre un problème ou atteindre l'exactitude. Si vous incluez du code inutile, les lecteurs vont passer une éternité à essayer de comprendre pourquoi cette ligne est ou était nécessaire avant de la supprimer; -).