Pas vraimentCitation:
Dans l'exemple cité If 6 Then, cela revient à écrire If 6=6 Then ce qui ne sert à rien.
La preuve :
(If 0 n'est pas évalué à 0 = 0)Code:If 0 Then MsgBox "oui"
Version imprimable
Pas vraimentCitation:
Dans l'exemple cité If 6 Then, cela revient à écrire If 6=6 Then ce qui ne sert à rien.
La preuve :
(If 0 n'est pas évalué à 0 = 0)Code:If 0 Then MsgBox "oui"
je ne comprend pas ton histoire de torchons et des serviettes!
true=-1 et false=0
dans tous les langage et cette règle vient du langage C et par extension au C++ un if qualifie si le résulta d'une expression retourne 0 ou pas!
maintenant je confirme que If 6 Then ne serre à rien mais c'est bien à l'origine de ce poste!
Écrire If X Then revient à écrire If X <> False Then avec X numérique
Edit: Si If X Then revenait à dire If X = X Then, alors If 0 Then reviendrait à dire If 0 = 0 Then, ce qui n'est pas le cas.
J'ai donc dis une connerie, je me suis moinssé moi-même
Je viens de faire le test en C :
Le desassemblage montre l'absence du code dans la boucle if (pas d'affichage de "test", appel direct de la fonction puts pour l'affichage de "fin". Dans le cas ou je remplace 0 par 1, le code contenu dans la boucle est présent au désassemblage et il y a affichage de "test" à l'execution, mais aucun test n'est effectué, tout comme si je met la valeur 6 ou -1Code:
1
2
3
4
5
6
7
8
9 int main() { if (0) { printf("test\n"); } printf("fin\n"); }
Le compilateur ne crée dans aucun des cas de test, celui-ci étant assez intelligent pour comprendre qu'un test est inutile. Dans cet exemple, on peut donc considérer qu'en cas de valeur 0 -> false que qu'en cas d'autre valeur -> true.
D’où l’importance d'utiliser true ou false et pas leur soi-disant valeur numérique, car d'un langage à l'autre ça peut changer.
Merci Christophe pour cette "preuve par désassemblage" très intéressante. Ayant appris l'informatique en autodidacte et ne l'ayant formalisée que très récemment par un bachelor, c'est par des expérimentations, parfois laborieuses :mouarf:, que je suis arrivé à ces conclusions qui, au moment même, me laissaient perplexes, la réflexion dans mon petit cerveau qui m'a permis de comprendre l'économie de calcul du processeur n'étant venue que plus tard.
Ton complément très instructif me plait donc beaucoup! ;)
Pour revenir et coller à la question posée par le demandeur -->>
Les expressions
Code:If true .....
sont d'habitude utilisées pour court-circuiter quelque chose (le plus souvent : une vérification).Code:If nombre_différent_de_0 ...
Elles sont souvent le fait d'un "intervenant" tiers désireux de "casser" une protection.
La seule chose qui me "turlupine", est le "exit sub" alors décidé. A moins que ce :
ait justement été mis juste avant un bloc d'instructions de protection et que ce bloc-là soit le dernier de la procédure et que cet "intervenant" n'ait pas voulu se priver de la faculté de remettre les choses en l'état en se contentant de mettre cette instruction en commentaires.Code:if 6 then exit sub
Mais même ainsi : pourquoi ne s'est-t-il alors pas contenté d'un simple Exit sub ? -->> mystère ...
J'aimerais vraiment voir la totalité du code mis dans la procédure concernée, à savoir :
Si code trop long, il suffira de ne montrer que la totalité du code situé entre cette instruction et "End Sub"Citation:
La ligne se trouve dans une macro "Worksheet_Change".
EDIT : j'aimerais également connaître le nom exact de la procédure concernée et sa déclaration complète .
EDIT 2 (je m'en veux de ne pas avoir pensé à cette hypothèse) : un "intervenant" tiers peut avoir remplacé par
une ligne disant originellement :Code:if 6 then exit sub
où toto serait une fonction (probablement de vérification.protection) retournant une booléenne ;)Code:if toto( .. paramètres éventuels ..) then
Il lui suffirait alors (soit manuellement, soit en intervenant par code sur le module de code de Woksheet) de remplacer à nouveau, à son gré, "6" par "toto( ....)" pour remettre les choses en leur état originel.