8 réponses à ce sujet

[Amhnemus]

Bonjour à tous,

N'ayant pas trouver de réponse satisfaisante ou pas de sujet en traitant je me lance.

Étant un noob pur en programmation malgré des essais sur mon bipède qui ce sont avérés fructueux je me rend compte que je dois progresser en programmation.

J'elabore un nouveau programme pour mon bipède mais une question me turlupine qu'est ce qui fait qu'un programme est mieux qu'un autre ? Quel sont les indices/ les outils qui permettent de programmer de façon optimale ?

J'imagine déjà qu'il faut minimiser le nombres d'instruction, minimiser le nombres de variables, adapter ses variables par rapport aux nombres quel doivent contenir.

Je pense avoir les réponses mais si je peux avoir d'autres avis, des conseils d'écriture, je posterai mes codes ainsi que la séquence de mon bipède dans le fil dédié à mon bipède.

Merci à tous

[R1D1]

Quelques conseils :
1/ le code doit être compréhensible facilement. Si tu décides de travailler avec quelqu'un, ou si tu reprends le projet après 1 mois, il faut pouvoir facilement re-rentrer dans le code existant. Pour ça, pas de miracles:
- nom des variables explicites
- les commentaires ne sont pas descriptifs ("création variable X" mais explicatifs "on crée la variable X comme "int" pour ignorer le bruit de mesure exprimé dans les virgules" -- attention, cette explication est purement fantaisiste, pour l'exemple)
- indentation (très important pour bien visualiser les blocs d'instruction)
2/ Ne te prends pas trop la tête sur le nombre de variable, leur taille, sauf si tu travailles sur processeur embarqué et que la place est limitée. Ton compilateur fera de toutes façons des optimisations mieux que toi.
3/ Sépare et organise ton code. Tu as besoin d'appliquer une fonction sur des valeurs ? Crée la fonction correspondante (voir l'exemple du capteur ultrason en Arduino qui convertit entre temps et distance) pour pouvoir l'appeler quand tu en as besoin plutôt que copier/coller ton code.
N'hésite pas à faire plusieurs fichiers et à utiliser les mécanismes d'inclusion (e.g. #include en C/C++, import en Python) pour rendre le code plus compréhensible. Une règle pratique dit que le code d'une fonction devrait tenir dans une hauteur d'écran. À ne pas suivre strictement, mais ça peut te guider pour voir où simplifier / mieux organiser ton code.
Si ton langage le permet, jette un oeil à la programmation orientée objet, c'est extrêmement pratique pour faire du code modulaire et réutilisable (mais ça prend du temps et de la pratique à bien maîtriser).
4/ Lance-toi, code un truc moche. Ça marche ? Reprends ton code et dégraisse-le, vois où tu peux le simpiifier. Tu es bloqué à un moment par des choix précédents ? N'hésite pas à repartir d'une version plus primitive et à faire les choses différemment. Un outil de versioning (git, svn) aide à ce niveau, même si ça demande également un temps d'apprentissage.
5/ Les erreurs que tu peux anticiper sont traitées (e.g. mon programme travaille sur un fichier de données, je vérifie que ce fichier a bien été passé à mon programme avant d'exécuter les instructions suivantes ; ou je quitte avec un message explicite).

Pour résumer : un "bon" programme est structuré, modulaire. Chaque module fait une tâche bien précise. Il est testé, si possible de manière automatique (e.g. tu as un petit programme à côté qui prend chaque module et qui le "torture" avec plein d'entrées différentes et vérifie que tout se passe bien). Une petite modification ne change pas totalement le comportement du programme.
N'hésite pas à dire si tu veux plus de précision sur certains points. Il ne s'agit pas forcément de conseils sur le code lui-même, mais plus de méthode dans la conception d'un programme complexe.

[thermo_nono]

Je crois que R1D1 a dit le principal.. 
-ecrire des commentaires. 
-utiliser des noms de variable et de fonctions explicites
-mettre toutes les parties du programme dans des fonctions (au nom explicite) qui seront appelées une à une par le "main". 
bonne prog.. surtout il faut te dire que tu sera peut être amené à revenir bidouiller ton prog dans un an ou deux, qu'il aura passé d'ici là de l'eau sous les ponts et qu'à ce moment un programme bien structuré et commenté te sera d'une grande aide. 

 

[Amhnemus]

Merci à vous deux

Effectivement le fait de commenter me permet déjà de lire mon code plus facilement, j'avais déjà fait un premier jet fonctionnel mais lourd et long que j'essaie de réduire et d'optimiser et je me rend compte que certaines choses ne servent à rien et surtout des noms de variables trop long qui a chaque fois le demandais de revenir plus haut pour voir comment je l'avais écrit mdr.

J'essaie aussi de le structurer de manière claire et lisible et pas faire du pavé indigeste.

Vous m'avez apporté quelques pistes pour le futur à ce qu'il me reste à travailler surtout pour créer des fonctions utiles et utilisable au bon moment.

Je vois que je vais sur la bonne voie je posterai prochainement mon code et voir avec vous ce qu'il ne va pas ou comment l'améliorer.

Merci encore

[cocothebo]

Je pense que les conseils pricipaux ont déjà été donnés.

 

Un point peut être, ne pas vouloir réinventer la roue (sauf dans un but vraiment pédagogique), donc utiliser à fond ce que permet:

• le langage, par exemple plutôt que faire des "if ... else if .... else if ... etc", utiliser un "switch" si disponible
• les "sucres syntaxiques" qui ne sont pas vraiment la syntaxe du langage mais plutôt des choses que le compilateur va savoir traduire et qui permettent d'améliorer la lisibilité du code; un exemple existant dans tous les langages est l'écriture des nombres suivant leur base (10 en décimal s'écrit  1010 en binaire, A en hexa, etc.)
• les APIs (bibliothèques), la libC par exemple donne bcp de choses plutôt pratique donc autant les utiliser, sur arduino ya une tétrachiée de bibliothèques pour tout et n'importe quoi...
• le compilateur quand on veut optimiser (c'est souvent caché mais ya pleins d'options de compilation), mais ça c'est loin après les 2 points du dessus.

 

Attention aussi il est fait mention "d'optimiser" qui est un bien grand mot mais qui à la fin est souvent très compliqué et surout veut tout et rien dire. On peut virtuellement tout optimisé mais pas tout en même temps, la taille de code, la RAM occupée, la profondeur de pile, la vitesse d'exécution etc. A la fin on aura toujours un compromis à faire (par exemple reduire la place mémoire augmente le temps de calcul).

 

 

Un dernier petit point pour la lisibilité, des fois suivant les langages il est meilleur de ne pas utiliser certains mots clés, par exemple les goto en C restent pas le mieux à utiliser sauf cas particulier.

[Amhnemus]

Merci cocothebo pour ces précisions supplémentaires je cherche surtout à rendre un code lisible, pratique à réutiliser par moi même ou d'autres par la suite sans mettre des choses inutiles ou répétitifs sans grand intérêt. Utilisant les bonnes boucles ou conditions / test au bon endroit au bon momen.

Bien sûr je ne cherche pas à réinventer la roue mais savoir a bien s'en servir.

Pour la suite cela sera en postant du code et d'attendre vos remarques pour savoir quel sont les points à retravailler.

Merci à toutes vos réponses qui me donne une bonne direction à suivre. Merci

[Melmet]

As tu déjà pensé a acheter des livres? 

[Amhnemus]

Il y a fort longtemps il y a une dizaine d'années mais je pensais que sur le net je trouverai beaucoup plus d'informations mais je me rend compte que c'est un peu la croix et la bannière. As tu des ouvrages à me conseiller et où se les procurer pour occuper les longues journées sur la plage pendant que madame bronze

[Oracid]

J'ai fait de la maintenance de programmes écrits en Assembleur(IBM) et Cobol pendant une dizaine d'années.
Pas des petits programmes. Quand tu avais un listing de 10cm d'épaisseur sur ton bureau, la sueur te perlait au front.
Sur chaque programme, une bonne centaine de programmeurs avaient apporté des modifications, peut-être plus.
C'est cela la vraie vie dans les pôles informatiques des entreprises du CAC40. Enfin, c'était, mais il parait que cela n'a pas beaucoup changé depuis 5 ans que je suis à la retraite.
Et bien, je peux vous dire qu'il y a un petit souci quand à la lisibilité des programmes.