Discussion :

[elmcherqui]

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]

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]

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]

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

Thierry

[ram-0000]

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]

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

[Emmanuel Delahaye]

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]

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.