Bonnes pratiques

[ouadji]

voici le code d'un sous-VI (code "théorique" minimum juste pour illustrer la question)

Je le présente sous deux formes : Code A et Code B

J'ai toujours codé mes sous-Vis sous la forme A (j'allais presque dire "évidemment")

mais ... je me pose la question suivante :

La forme B est-elle non valide ? et si oui, pourquoi ?

Est-ce juste une question de "bonnes pratiques graphiques" de préférer la forme A ?

Ou existe-t-il des raisons "plus en profondeur" ?

Que dit le compilateur ? Préfère-t-il réellement une forme plutôt que l'autre ?

Pourtant ... les deux formes ne semblent poser aucun soucis à Labview, et les deux codes A et B tournent sans problèmes.

et si la forme B était plus rapide à l'exécution ?

Quels seraient les inconvénients - dangers - soucis - problèmes quelconques ... que pourrait poser la forme B ?

[R3g]

Salut,

Je fait comme toi, je privilégie le Code A, permet de visualiser tous les commandes du Vi sans aller les chercher dans les diffécrents cas de la structure.

La réponse à ta question m'intéresse aussi.

[BenjaminR]

Salut Ouadji, 

Le code A permet une meilleure lisibilité de ton programme, on connait directement l'ensemble des entrées de ton VI. 

Je me permets d'attirer ton attention concernant la place des sorties, indicateurs, qui a une très grande importance lors de la compilation. En effet, un indicateur à l'intérieur d'une structure condition (Conditional indicator) va créer un nouveau Data Buffer. L'explication ici. 

Autre point, il faut essayer d'éviter les structures imbriquées qui rendent le code pas lisible. Il faut regarder chaque cas pour déterminer comment sont gérer les données et comment sont obtenus les sorties. 

[Desruelle_luc]

salut à tous, la note d'application donnée par Benjamin est vraiment à connaître pour optimiser la gestion des données sous LV.

une version française...

http://zone.ni.com/reference/fr-XX/help/371361J-0114/lvconcepts/vi_memory_usage/

pour info en cherchant sous google avec "lvconcepts LabVIEW" il y a d'autres "lv concepts" à lire

A+

[ouadji]

Bonjour Benjamin,

Le code A est plus lisible ... on "voit" facilement toutes les entrées .... ok, 100% d'accord avec toi.

Attention aux sorties .... un nnouveau "data buffer" .... ok. (je vais lire la doc de ton lien)

Je précise (re) que je ne code jamais suivant le code B, la question (débat ouvert) était plutôt d'une dimension prurement théorique.

éviter les structures imbriquées (???)

là .... oui, "on" essaye   (bien entendu)   .... mais faire du code un rien complexe sans structures imbriquées,

autant chercher à fabriquer une voiture sans devoir plier aucune tôle.

en pièce jointe "unsafe.vi" (c'est un code qui regarde si un Roi sur un échiquier est en prise ou pas)

Dans ce vi, j'ai 6 structures imbriquées. 

Je lance le défi à quiconque pourra me réaliser cette fonction, avec un code plus rapide que le mien,et avec moins de 6 imbrications. (attention à la conrainte "plus rapide que" )

et la question : éviter les structures imbriquées ... ok, mais pourquoi ?

PS:

si quelqu"un veut réellement se frotter au défi, je lui donnerai les infos supplémentaires.

[ouadji]

Merci Luc pour la version en français !

[Eric.M]

Structures imbriquées :

• À l'édition d'un VI:
• diminue la lisibilité du code - et les facilités de debug
• Demande plus de mémoire à LabVIEW pour la manipulation du diagramme (son rafraichissement !)
• Alourdit la taille du VI - chaque sous-diagramme a sa représentation en mémoire (ce qui permet notamment de les scripter)
• À l'exécution d'un VI:
• Rallonge les tests unitaires à cause de la couverture de code
• Demande plus de mémoire (plus de buffers de données, et de buffers opérationnels)
• Risque pour la stabilité (plus de boucles ou/et plus de cas imbriqués => plus de conditions à vérifier par opération => risque)

En soit, avec un bon PC et l'habitude de lire des VIs, les inconvénients d'édition sont balayés. Par contre, dans une approche de performance et de projet (l'évaluation des risques et la validation sont devenues des parties prépondérantes dans le cycle de développement), la deuxième partie est importante.

A+

--Eric

[ouadji]

Bonjour Eric,

avis "très pro" (qui a bien évidemment sa place ici ... peut être même "surtout")

lisibilité : nous sommes d'accord, question d'habitude.

plus de mémoire : je suis d'accord ...  question de contrainte principale, taille ou vitesse (l'un excluant l'autre dans 99% des cas)

rallonge les tests : suis d'accord ... plus il y a de structures imbriquées, plus l'algorithme globale est complexe.

au risque d'irriter ... question de capacités personnellles.

Ne jamais construire un code qui dépasse votre capacité à le maitriser.

La stabilité ?

c'est une notion (que je comprends parfaitement) mais qui me laisse toujours un peu perplexe.

La notion de stabilité induit obligatoirement que l'on suppose ne pas connaître la totalité du fonctionnement-comportement du code.

On "accepte" qu'il puisse exister des "cas non connus" qui pourraient placer le code dans une position instable, donc non définie. (pour faire court ... un bug)

Pour moi, un code vis à vis duquel au accepte la notion de stabilité est un code qui ne pourra jamais être autre chose qu'une version bêta.

Ceci dit, oui ... plus un code est complexe, plus la possibilité d'avoir un (ou des) bug est élevée.

Cela me laisse une impression curieuse (peut-être bien réelle dans le monde du soft "commercial")

Il y aurait comme un rapport "temps de développement - gain" (je comprends cela)

qui ferait qu'à un certain moment, on "laisse partir" un programme en sachant très bien qu'il est possible qu'un ou plusieurs bugs soient toujours présents.

D'où cette notion de stabilité.

Ceci dit, le sujet est complexe (et quasi philosophique)

Au delà d'une certaine complexité, qui peut affirmer qu'un code ne contient aucun bug ?

Merci pour ton intervention Eric.

Elle ouvre la réflexion. Réfléchir et douter de ses propres certitudes est peut-être le plus important.