Les opérateurs logiques (&& et ||)

Bonjour à tous,

Juste un tout petit tuto pour bien utiliser ces opérateurs logiques.

Ça va vous paraître ridicule et certains ne l'ouvriront même pas, cependant je ne vais pas trop expliqué ici le rôle de ces opérateurs mais bien leur fonctionnement et comment économiser des ressources.

Rappel a écrit:

&&
Le ET logique vérifie si les deux côtés de l'expression sont vrais, si oui il renvoie vrai. Si un ou les deux côtés sont faux, il envoie faux.

||
Le OU logique vérifie qu'au moins un des deux côtés de l'expression soit vrai, si oui il renvoie vrai. Si les deux côtés sont faux, il renvoie faux.

Bon alors ce que je vois souvent :

Code:

if(from != null)
{
   if(from.Str > 60)
   {
      from.SendMessage("C'est bien vous avez plus de 60 en force !");
   }
}

Ou encore :

Code:

if (ns.Mobile.Skills[SkillName.DetectHidden].Value > from.Skills[SkillName.Hiding].Value - 20 && ns.Mobile != from)
   from.RevealingAction();

Ce qu'il faut savoir c'est que le logique signifie qu'ils ne vont pas plus loin que nécessaire.

Donc par exemple dans le premier exemple, écrire :

Code:

if(from != null && from.Str > 60)
{
   from.SendMessage("C'est bien vous avez plus de 60 en force !");
}

Ne fera pas crashé le serveur car il ne passera pas dans le from.Str > 60 si from est null.

Donc pour le &&, si la première partie de l'expression est false, il sait que ça ne sert à rien d'aller plus loin car même si la deuxième est vraie, il devra renvoyer false. Du coup il n'évalue pas la deuxième partie de l'expres​sion(ça peut être un piège si l'on appelle des méthodes qui font tu travail persistent sur des données en plus de renvoyer un booléen).

Pour le || c'est pareil, si la première partie de l'exression est true, il sait que ça ne sert à rien d'aller plus loin car même si la deuxième partie est false, il devra renvoyer true. Du coup il n'évalue pas non plus le deuxième partie de l'expression.

Alors du coup comment bien organisé ses expressions booléennes dans ses if et autres?

Et bien moi je trouve ça intéressant d'économiser au maximum les ressources de l'application en mettant à gauche la partie qui demande le moins de travail, ainsi si il ne faut pas évaluer la deuxième partie, on économisera un gros boulot (bon à l'heure des ordinateurs actuels ce n'est pas grand chose ^^).

Voici le deuxième exemple corrigé :

Code:

if (ns.Mobile != from && ns.Mobile.Skills[SkillName.DetectHidden].Value > from.Skills[SkillName.Hiding].Value - 20)
   from.RevealingAction();

Pourquoi? Parce que comparé deux objets dans la première partie ne fait qu'une comparaison des adresses mémoires des objets (références), du coup ça ne coute pas grand chose. Tandis que la deuxième partie, accède à de multiples champs, tableaux à des indices, comparaison et soustraction.

Bon ici ce n'est pas très parlant et le gain est minime (si pas nul ^^). Mais dans d'autres exemples tels que vérifie si une longue liste contient un élement, il peut s'agir d'un coût bien plus important.

Dernier exemple bien couteux si on s'y prend mal. Supposons la liste de nombre réels suivante remplie de 100.000 nombres aléatoires entre 0 et 1 non compris grâce à Utility.RandomDouble();

Code:

List<double> pleinDeNombres = new List<double>();

for(int i = 1; i <= 100000; i++)
{
   pleinDeNombres.Add(Utility.RandomDouble());
}

Maintenant supposons que je dois vérifier si cette liste contient un nombre donné en paramètre, uniquement si le Mobile n'est pas un monstre.

Il y a donc deux façon de faire :

Code:

public bool maMethodeMauvaise(Mobile m, double nombre)
{
    return pleinDeNombres.Contains(nombre) && m.Player)
}

public bool maMethodeBonne(Mobile m, double nombre)
{
   return m.Player && pleinDeNombres.Contains(nombre);
}

Vous remarquez que dans la première méthode, on vérifie d'abord si la list contient le nombre, ce qui peux être très couteux si la liste est grande et compliquée (contient des objets avec .equals à la clef), ensuite si la liste contient le nombre elle vérifie si m est un Player, et renvoie vrai si les deux sont vrais.

Tandis que dans la deuxième méthode, si m n'est pas un joueur, nous n'irons pas vérifier que pleinDeNombre contient bien le nombre passé en paramètre. Et nous économiserons donc le parcourt de la liste qui se passe dans la méthode Contains afin de vérifier qu'elle contient bien le nombre en question.

Voilà c'est con mais certains ne se servent pas bien des opérateurs logiques donc si ça peut aider un peu tant mieux