framboise314.fr

Passons a la dernière partie, a savoir la sortie 'propre du programme.

Dans sa sortie de programme, Frédéric a voulu faire les choses bien en prenant soin de libérer les GPIO utilisées (c'est très bien ca).
Pour ça il a utilisé l’appel GPIO.cleanup, c’est très bien, mais ensuite il a fait une grosse erreur en pensant bien faire en voulant redéfinir l’état des sorties à l'exit du programme. C‘est une erreur dans le sens ou cette série d’instructions (celles de la def ExitFunction) est exécutée après GPIO.cleanup, ce qui a pour effet de réattribuer les IO qui avaient été proprement libérées par l’instruction GPIO.cleanup (d’où les warning quand il redémarre son programme …).

Juste pour comprendre, faisons un petit test avec ce code :
La sortie est initialisée avec un état bas, puis elle passe à un état haut quand on la définie HIGH et elle revient toute seule a un état bas au bout de 5 secondes quand le programme passe l’instruction GPIO.cleanup. Le rôle de GPIO.cleanup, c’est justement de remettre toutes les IO que le programme à initialisé en l’état ou il les a trouvés en arrivant. C’est donc la dernière instruction que le programme doit exécuter sur les IO pour les libérer proprement et il n’y a besoin de rien d’autre.

Pour une sortie propre on peut donc supprimer complétement la def exitFunction() ainsi que la ligne atexit.register qui l’appelle et on a plus besoin d’importer atexit et ca se résume a ca :

Voila, on a fini de simplifier tout ça sans ajouter aucune complication. Rassemblons les morceaux et voilà le résultat du code complet.

Bien sur ce n'est pas du code de gourou. On a pas utilisé d'objet ou d'itération et encore moins d'évènement, mais ce code est tout a fait acceptable et parfaitement fonctionnel en plus d'etre à la portée de n'importe quel débutant.

On a toujours juste notre boucle while et des 'if' 'else' simplifié, rien de plus et pourtant la longueur du code a bien diminué. Voila ce que ca donne en comparaison (image réduite mais code au meme ratio de zoom)
Dans les commentaire sur le blog, Frédéric a écrit ca :
ce schema comporte des transistors car au debut je souhaitais que si une led s allume, les precedentes aussi

On verra la prochaine fois comment on peu résoudre ca et croyez moi pas, il y a de forte chance que ca permette de réduire encore plus le code

C’est vrai qu’un vumètre qui affiche les leds de façon progressive plutôt que de façon unitaire, ça a quand meme plus de gueule (et ça justifie pleinement l’usage des transistors ) En plus, ça tombe bien, ça fait encore moins de code (ce qui n’aurait pas été le cas avec un code minimaliste …). Il suffit pour ca de juste modifier les seuils dans les instructions d’écriture des états des leds sans plus se soucier de la partie inferieur.

Pour ce genre de chose, je vous recommande des leds rectangulaire disposées jointives les une à la suite des autres dans le sens horizontale s'il y en a peu et dans le sens verticale s'il y en a beaucoup. Ca n'apporte techniquement rien de plus que les rondes, mais je trouve ca plus joli

Salut à tous.

Frédéric a écrit :C'est vrai que le but de ce tuto n est pas de faire "le plus cout possible" mais bien d'emmener un débutant, comme moi, entre autre, a avoir une réflexion de développeur et donc d utiliser tous les outils disponibles, comme limiter les lignes inutiles, utiliser tous les outils disponibles (doc, arithmétiques, etc). Je crois que le but est atteint.

La première règle que vous devez apprendre est de rendre votre code lisible.
Il ne s'agit pas d'utiliser des astuces dont vous êtes le seul à connaitre la signification.

La deuxième règle est d'éviter de faire de la répétition.
Si vous ne pouvez pas faire autrement, utilisez des procédures ou des fonctions.

La troisième règle est de bien structurer votre programme.
Vous devez faire l'usage de la programmation structurée, ainsi que de modules (sous-programme) quand cela est nécessaire.

La quatrième règle est toujours de faire le plus court possible, en respectant les règles précédentes.
Entre un programme qui fait quinze pages et un autre qui fait disons une demi page, sachant qu'ils font exactement la même chose, lequel selon vous doit-on priviliégier ?

La cinquième règle est de rendre votre programma à l'exécution le plus rapide.

Frédéric a écrit :Ps: si je met 10 min pour écrire 10 lignes de codes, vaut il mieux pour moi que j’écrive 40 lignes sans réflexion où réfléchir 5~10 min et écrire seulement 20 lignes de code...

Pourquoi utiliser un chronomètre pour écrire votre code ? Vous ne devez pas confondre vitesse avec précipitation !

Un programme ne s'écrit pas en un seul jet.
Un programme se construit étape par étape, même si au final, tout semble être logique et bien construit.
Vous devez l'écrire en faisant des tests, mais surtout en comprenant ce que vous faites.
Le découpage est tout aussi important que la lisibilité.
Et ce que vous montre " Bud Spencer", c'est la démarche à suivre pour analyser votre problème et ensuite l'écrire.
Il n'existe pas une seule solution à ce genre d'exercice.

Un programme trop court, donc illisible est à rejeter.
Un programme trop lent est aussi à rejeter.
Vous devez trouver le juste milieu entre ces deux approches.

Bud Spencer a écrit :Tu verras que si tu prends l'habitude d'utiliser des opérateurs ternaire (qu'importe le langage), tu auras du mal à t'en passer et ca deviendra naturel.

Je ne suis pas d'accord car ce sont des astuces de programmeurs confirmés et non destinés à un débutant.
La programmation, c'est comme le piano, quand on est débutant, on fait régulièrement ses gammes et non de s'attaquer à une symphonie.
Le mieux est encore d'utiliser la structure "IF ... THEN ... ELSE ... END-IF", qui est compréhensible par tout le monde.

@+

Bonjour a tous (tes), mon probleme c est que je code pour coder et non ppur avoir un code efficace et bien lisible
@Artemus c est vrai que je me precipite mais j y travail.
@Bud Spencer si un seul GPIO.cleanup dans finally est exécuté dans tous les cas de figure, c est beaucoup plus simple. Pour les leds allumées en même temps, il est certain que je piquerai ton code

Artemus24 a écrit : ↑

mer. 31 juil. 2019 01:45

Je ne suis pas d'accord car ce sont des astuces de programmeurs confirmés et non destinés à un débutant.

Absolument pas. Les opérateurs conditionnel existent dans pratiquement tous les langages et font partie des premières choses que l’on apprend (ou que l’on enseigne …) en école au meme titre que tous les autres opérateurs. Les seuls qui ne les utilisent pas ce sont juste les très débutant autodidacte qui ne les ont pas encore découvert par eux meme ou qui n’ont pas le reflex de les utiliser. Si on s’en tient au rôle primaire d’un opérateur conditionnel qui est d’affecter une valeur ou une autre en fonction d’une simple évaluation, il ni a rien de plus facile à lire et à ecrire. Il suffit juste de savoir que ça existe, comme tout le reste.

Si un débutant est capable de comprendre ca : Il comprendra tout aussi facilement ça : Au pire il admettra qu’’il ne savait qu’il pouvait l’ecrire aussi simplement, mais maintenant, il le sait …
De toutes façons, on s'en fout, il ni a pas d'operateur conditionnel dans le code final que j'ai fourni. Je m'en suis juste servi en transition d'explication pour arriver a un résultat encore plus simple.

Frédéric a écrit : ↑

mer. 31 juil. 2019 07:15

@Bud Spencer si un seul GPIO.cleanup dans finally est exécuté dans tous les cas de figure, c est beaucoup plus simple. Pour les leds allumées en même temps, il est certain que je piquerai ton code

C’est le plus simple que tu puisses faire à ton niveau pour l'instant et c'est très facilement déchiffrable pour n'importe quel débutant qui sait déjà allumer une led avec son PI. Si on regarde bien, à l’exception de la partie arithmétique que tu aurais sans doute amélioré toi-même par la suite, toute cette réduction tiens à un seul details. Il suffisait juste de penser à placer l’évaluation qui définit l’état de la led directement dans l’appel de la fonction (GPIO.output), rien de plus .

Comme on avait évoqué les listes et les itérations, je t'écrirais comme promis un ou deux autres exemples plus 'évolué' qui t'aideront peut etre a progresser.