Question de bââse

Bonjour à tous !
J'ai une question qui pour moi est une évidence, mais je suis en train de lire du code depuis quelques jours, et je me dis, que je dois me planter complètement :x


Question 1 :
Qu'elle est la l'instruction qui dure le moins longtemps en mémoire : SI ? POUR ? SELON ?

Question 2 :
Qu'est ce qui vaut mieux faire :

Code:

---

1 2 3 4 5 6 7 8

SI a="1" SI b = "2" SI n = "3" ALORS n="0" FIN FIN FIN

---

OU

Code:

---

1 2 3 4

SI a="1" ET b="2" ET n="0" ALORS n="0" FIN

---

Voila.

Ca me donne des boutons, le code est partout comme ca avec des
SELON Z
SELON Y
SELON X

et autre... Alors je me demande si j'ai raison ou si je me bloque pour pas grand chose.

Merci beaucoup pour vos éventuelles réponses !

Ben ça dépends du langage :)

si ton langage examine toutes les conditions dans un if, le si a & b & c ... sera plus long que si a, si b, si c ...Si au contraire il arrête dès qu'une condition est fausse, les deux formes de si sont équivalentes.

Ensuite, je ne sais pas ce que fait ton appli, mais s'il y a par ex. des accès fichiers ou bases de données, le temps passé dans les tests est insignifiant par rapport à celui de ces accès.

Et je te parles pas d'une appli. interactive ou elle passe 99% de son temps à attendre que l'interface chaise/clavier s'active ;)

Je suis sous WinDev (...). L'application est assez conséquente (plusieurs milliers de ligne).
Mais quand je vois une procédure qui fait 3000 lignes avec 70-100 SI ou SELON comme je l'ai présenté ci dessus, je me dis que ce n'est pas si insignifiant que ca .

Parce que si j'améliore toutes les procédures et que je gagne ne serait-ce que 30 ou 40 SI par procédure, je pense que ca peut être intéressant.

Tout dépends du nombre de fois ou ta proc. est utilisée : si c'est dans une boucle en centaines de milliers, ça peut être intéressant (j'ai bien dit "ça peut" hein et encore, tu ne va gagner que quelques millièmes de seconde, à toi de voir si le temps que tu va y passer vaut le temps gagné à l'utilisation ), si c'est 1000 fois, tu a certainement d'autres moyens d'optimiser.

Après si c'est pour réduire ta proc. de taille, regarde plutôt pour la découper en plusieurs. Ca sera plus lisible et plus maintenable (un des mes profs. m'a toujours rabaché : je ne veut pas de proc. qui fait plus d'un écran de long ! si ça dépasse, c'est qu'elle est trop complexe et que tu a mal analysé ton traitement, ben je continue sur la même voie^^).

Sinon, c'est quoi "selon" comme structure de contrôle ? "select/case" ?
Pour réduire des select case, je ne connais pas de SilverBullet.
Ca dépends aussi du langage, de ce que tu veut faire, etc...

Par ex. avec VB6, "choose" peut parfois remplacer un select/case la ou un langage sans équivalent va t'obliger à utilise ce select/case, etc...

Mais à mon avis, te braque pas sur les SI en tant que tel, regarde plutôt comment découper ta proc.
A la rigueur, des fois tu peut remplacer de "groupes" de condition par une variable.
par ex: tu a plusieurs fois

Code:

---

if a & b & c

---

sans que a,b,c ne soient modifiés entre deux if ? une variable

Code:

---

v=(a & b& c)

---

puis tu remplace tes if par

Code:

---

if v

---

...ça revient au même fonctionnellement mais 1) l'évaluation du "a & b & c" n'est faite qu'une fois 2) code est - à mon sens - plus lisible.

> Sinon, c'est quoi "selon" comme structure de contrôle ? "select/case" ?

C'est bien ca.


Mais tu as répondu à ma question, je te remercie. Je vais pousser ses idées : découper ces procédures sans fin, et arrêter de me bloquer sur ces instructions.
Merci en tout pour avoir éclairer ma lanterne.