Sauf si vs en Javascript avec l'utilisation du point d'exclamation?

Le code ci-dessous tente d'imprimer "est même" pour les nombres divisibles par 2.

Ne devrait-elle pas être si (test) alors() au lieu de: if (!test) alors(), si la condition testée est "n % 2". Le code ci-dessous semble lire "SI les chiffres ne sont PAS divisibles par 2, imprimer 'nombre est même' ", ce qui ne semble pas logique.

De manière plus générale, quels sont les avantages de l'écriture d'un, à Moins que la fonction à l'aide d'une instruction if dans la spécification d'état, lorsque ce que nous pourrions faire est de simplement écrire if (!condition)?

Toute aide est très appréciée.

function unless(test, then) {
  if (!test) then();
}
function repeat(times, body) {
  for (var i = 0; i < times; i++) body(i);
}

repeat(5, function(n) {
  unless(n % 2, function() {
    console.log(n, "is even");
});
//→ 0 is even
//→ 2 is even
//→ 4 is even
% n'a pas de test de divisibilité. C'est un modulo de l'opérateur. Ce code permet de tester si n % 2 évalue à quelque chose qui pourrait être considérée comme fausse (aka 0) et, si oui, il est même.
"Le code ci-dessous tente d'imprimer "est même" pour les nombres divisibles par 2." ne sont pas essayer, . (Au moins, une fois que vous avez corrigé l'erreur de syntaxe à la fin, il le fera.) De toute façon, je suis d'accord que l'idée de "si" n'est pas vraiment du point de vue sémantique pour ce test, mais le code ne ont souhaité en sortie. Ces types de fonctions regardez comme ils appartiennent à un framework de test, vous permettant de faire une assertion et ne quelque chose si l'assertion s'avère faux.
Ce code est horrible, comme en témoigne le fait qu'il n'est même pas clair ce qu'il fait sans une analyse minutieuse. Il n'y a pas d'avantage ici. Je ne peux pas citer des avantages dans le cas général. Peut-être qu'il est avantageux de le faire de cette façon, lorsque votre pointues, cheveux patron dit de le faire de cette façon, ou vous serez congédié. Vous avez besoin pour donner le contexte pour que vous pouvez, pour cette question, pour être viable.

OriginalL'auteur Henry | 2015-01-23

  1. 4

    La défendable avantage, c'est que le code se lit un peu plus comme l'anglais: "à Moins de n modulo 2 est différent de zéro, connectez-vous à la console que n est pair."

    Dans mon expérience, la conséquence pratique de cette est que la plupart des programmeurs devront aller de double-vérifier ce que, à moins que() ne fait avant de se sentir à l'aise avec elle. Parce que ce n'est pas un norme morceau de Javascript, ils n'ont aucun moyen de savoir si on utilise ! ou ==true ou ===0 ou quelques autres toujours aussi légèrement différente de test, à moins d'aller chercher à la mise en œuvre.

    Mon exemple favori de ce principe est en COBOL. Cette langue a essayé très dur pour ressembler à de l'anglais, de sorte que même les non-programmeurs pourraient l'utiliser...mais dans la réalité les deux programmeurs et les non-programmeurs semblent hate de travailler avec elle.

    J'ai pratiquement d'accord avec tout ce que vous avez écrit dans ce contexte. Cependant, Perl tire de cette très élégamment lorsque utilisé de la manière suivante: go_outside() and play() unless $is_raining;. Dans cet exemple précis il n'y a pas de peine à l'utiliser, mais comme avec tout ce qui en Perl, il peut facilement être abusé dans les moyens qui rend le code moins lisible.
    lol @ "moins ils aller chercher à la mise en œuvre"

    OriginalL'auteur Ixrec

  2. 1

    Il n'y a pas d'avantages si la condition est fourni en ligne, comme dans ce scénario. Vous pouvez facilement appliquer une transformation à le nier comme il convient dans tous les cas (par exemple en ajoutant un ! à l'avant), et en prenant unless hors de l'image signifie qu'il y a une chose de moins que le lecteur doit connaître.

    Il pourrait être un avantage si la condition a été fournie sous la forme d'un rappel, par exemple:

    function test() { return true; }
function unless(test, then) { if (!test()) then(); }

unless(test, function() { console.log("test failed"); });

    Dans cette situation, vous ne pouviez pas passer directement de la négation de test à une fonction hypothétique onlyIf qui est complémentaire à la unless, afin d'avoir à la fois onlyIf et unless peut rendre le code plus lisible, car il vous permet de le faire:

    onlyIf(test, function() { console.log("test passed"); });

    au lieu de cela:

    onlyIf(function() { return !test(); }, function() { console.log("test passed"); });

    La situation ci-dessus pourrait être encore pire si le rappel est donné des arguments qui doivent être propagées dans test.

    OriginalL'auteur Jon