question sur une habitude de programmation en C

**elmcherqui** · 23/09/2008, 21h57

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 .

**Obsidian** · 24/09/2008, 00h32

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.

**pfeuh** · 24/09/2008, 08h11

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

**Thierry Chappuis** · 24/09/2008, 08h51

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

Thierry

**ram-0000** · 24/09/2008, 09h00

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.

**Thierry Chappuis** · 24/09/2008, 09h34

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

**wiztricks** · 24/09/2008, 14h34

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?

**ram-0000** · 24/09/2008, 15h49

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 ?

**wiztricks** · 24/09/2008, 15h56

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

**Emmanuel Delahaye** · 24/09/2008, 17h18

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

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).

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.

**Emmanuel Delahaye** · 24/09/2008, 17h25

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).

**Emmanuel Delahaye** · 24/09/2008, 17h27

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...

**elmcherqui** · 24/09/2008, 17h41

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

**Médinoc** · 24/09/2008, 18h22

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

**wiztricks** · 24/09/2008, 18h43

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

**Emmanuel Delahaye** · 24/09/2008, 19h00

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...