question sur une habitude de programmation en C

bonsoir ,
voila maintenant quelque temps que je programme en C mais rien de bien gros juste des algorithmes sur france-ioi qui ne dépassent pas les 100lignes . mais maintenant j'aimerais creer de plus gros programmes vu que j'attaquerai bientôt une lib et j'aimerais poser une question sur vos habitudes, en programmation modulaire .
admettons qu'on a tous écrit sur papier ( fonction dont on a besoin , ce qu'elle retournent , nombre variable )
mais quand on a écrit ces fonctions sur le fichier .c , est ce qu'on commence directement a ecrire le programme ou bien on les test une par une d'abord ?

j'aimerais savoir comment vous faite lorsque vous voulez attaquer un gros programme .
merci pour vos reponses et bonne soiree .

Citation:

---

Envoyé par elmcherqui

mais quand on a écrit ces fonctions sur le fichier .c , est ce qu'on commence directement a ecrire le programme ou bien on les test une par une d'abord ?

---

Je ne comprends pas trop où tu veux en venir. Si tu as écrit une lib, alors oui, elle est en elle-même un programme à part entière. Et comme, en plus, d'autres logiciels vont s'appuyer dessus, elle doit être irréprochable. La suite de tests doit donc être assez sérieuse.

Sinon, la seule chose qui permettent de mener à bien de gros projets, c'est la rigueur comme partout.

- Prends l'habitude de mettre des commentaires, même pour toi. Ce qui est évident aujourd'hui sera obscur dans un an.

- Reste cohérent (politique de nommage, prototypes de fonctions, etc.) à travers tout ton projet.

- Choisis la granularité de tes fichiers. N'utilise pas un seul gros fichier *.c pour l'ensemble de ton projet, mais découpe le plutôt en sections (par thème), ne serait-ce que pour éviter d'avoir à tout recompiler à chaque modif'. Au début c'est rapide, surtout aujourd'hui, mais très vite, ça devient lourd. Et quand tu passes du C au C++, c'est encore pire. Évidemment, ce n'est pas non plus la peine de faire un fichier par fonction (ou par classe, en POO, comme en Java).

- Utilise éventuellement un logiciel de versioning. Très pratique pour tout conserver au même endroit, faire du travail collaboratif, et se permettre de pouvoir faire évoluer son projet en se garantissant la possibilité de revenir au dernier état stable en cas de problème.

Après, il existe des méthodes scientifiques pour mener de gros projets et garantir, autant que faire se peut, la validité du logiciel produit, mais ça devient très costaud.

Salut,

Si je devais faire une lib, j'assurerais d'abord un gros jeu de tests unitaires. chez Emmanuel: http://delahaye.emmanuel.free.fr/spip.php?article23

A+

Pfeuh

Une bonne pratique est d'écrire les tests avant d'écrire la fonction.

Thierry

Citation:

---

Envoyé par Thierry Chappuis

Une bonne pratique est d'écrire les tests avant d'écrire la fonction.

Thierry

---

Je dirais plutôt que : Une bonne pratique est de décrire les tests avant d'écrire la fonction.

Citation:

---

Envoyé par ram-0000

Je dirais plutôt que : Une bonne pratique est de décrire les tests avant d'écrire la fonction.

---

Personnellement, je les écrits et je les exécute régulièrement au cours du développement de la fonction.

Thierry

Je serais plutôt d'accord avec ram-0000: avant d'écrire il est utile de décrire.
Ensuite côté codage, on peut commencer par les tests surtout si les fonctions sont dans un premier temps réduites à un "mockup".
- W
PS: "mockup" on traduirait cela comment dans notre langue?

Citation:

---

Envoyé par wiztricks

Ensuite côté codage, on peut commencer par les tests surtout si les fonctions sont dans un premier temps réduites à un "mockup".
- W
PS: "mockup" on traduirait cela comment dans notre langue?

---

Je dirais "fonction bouchon" si j'ai compris ce que tu veux dire : fonction vide, sans traitement, qui respecte l'interface d'appel de la future fonction et que l'on peut appeler.

J'ai bon ?

Citation:

---

Envoyé par ram-0000

Je dirais "fonction bouchon" si j'ai compris ce que tu veux dire : fonction vide, sans traitement, qui respecte l'interface d'appel de la future fonction et que l'on peut appeler.

J'ai bon ?

---

"fonction bouchon" me va bien...
merci
- W

Citation:

---

Envoyé par elmcherqui

maintenant j'aimerais creer de plus gros programmes vu que j'attaquerai bientôt une lib et j'aimerais poser une question sur vos habitudes, en programmation modulaire .
admettons qu'on a tous écrit sur papier ( fonction dont on a besoin , ce qu'elle retournent, nombre variable )

---

Il y a 2 choses importantes à spécifier :

• L'interface
  
  • Nom de la fonction
  • Type retourné
  • Paramètres
• Le comportement attendu.
  
  • Nominal
  • Extrême
  • Hors limites

Citation:

---

mais quand on a écrit ces fonctions sur le fichier .c , est ce qu'on commence directement a ecrire le programme ou bien on les test une par une d'abord ?

---

Il y a plusieurs façons de faire. J'aime commencer par les tests.

On écrit les scénarios de test en s'appuyant sur la spécification détaillée (exposée au-dessus), et on appelle la fonction (au début, vide). On retourne quelques erreurs 'en dur' pour valider le test, puis on commence à coder la fonction 'sous le contrôle du programme de test'.

Dès qu'on a écrit quelques lignes de code stables (0 warnings), on exécute et on interprète les résultats du tests (commencer par quelques tests basiques qui vérifient uniquement le comportement normal). Éventuellement on corrige, ou on constate que 'l'erreur est juste'.

Ensuite, on complète jusqu'à obtenir un comportement nominal conforme.

Ensuite, on teste aux limites. on corrige les éventuels bugs.

Enfin, on teste les hors limites, ça doit résister (pas de crash, arrêt de l'application, code retour particulier, message etc. selon la gravite).

Citation:

---

j'aimerais savoir comment vous faite lorsque vous voulez attaquer un gros programme .

---

1 - Une définition très solide
2 - Une grosse analyse descendante

(les points 1 et 2 sont récursifs et aboutissent à un arbre dont les feuilles sont des fonctions de base).

L'usage d'outils d'organisation comme FreeMind peut aider.

3 - une construction montante avec de tests unitaires en même temps

C'est le B.A. BA de toute construction industrielle (pont, immeuble, auto, nacire etc.). L'informatique n'y échappe pas.

Citation:

---

Envoyé par ram-0000

Je dirais plutôt que : Une bonne pratique est de décrire les tests avant d'écrire la fonction.

---

Les méthodes agiles cherchent à éviter la paperasse inutile.

Écrire le test avant le codage de la fonction permet d'éviter cette phase de rédaction qui n'apporte rien que de la perte de temps (le seul document important est la spec).

Citation:

---

Envoyé par wiztricks

"mockup" on traduirait cela comment dans notre langue?

---

Déjà, on ne dit pas mockup, mais stub. En français, leurre, bouchon, simulation...

merci emmanuel c'est precisement ce que je voulais savoir .

"mockup" s'emploie surtout en informatique pour une interface graphique, en fait.

Dans le monde du TDD, mock, stub, fake,... ont des définitions assez surprenantes côté précision.

Voir:
http://robsanheim.com/2006/01/19/nam...ock-stub-fake/
- W

Citation:

---

Envoyé par wiztricks

Dans le monde du TDD, mock, stub, fake,... ont des définitions assez surprenantes côté précision.

Voir:
http://robsanheim.com/2006/01/19/nam...ock-stub-fake/
- W

---

Effectivement. Mon stub se comporte comme un mock au début...

Citation:

---

Envoyé par Emmanuel Delahaye

Effectivement. Mon stub se comporte comme un mock au début...

---

ça vaudrait un post dans la Taverne, ça :aie:
;)