Discussion :

[funtix]

Hello,
En C existe t'il une méthode de conception pour éviter les problèmes ?

Quand je debute un projet, je commence par reflechir aux données et types que je vais manipuler. Tout mes efforts portent sur ca. Mais ca ne suffit pas...
En programmation objet, on se concentre sur les futurs objets, les interactions entre eux...
Le C est un language procedurale, est ce que ce sont les fonctions ou les données qui determine le devenir du programme...

Avez vous des liens, des livres ou des conseils a donner?
Merci

[hiko-seijuro]

Moi je fais plus ou moins du C objet de temps à autres sauf pour des routines précises. Je pense qu'il faut que tu t'adaptes à ce que tu veu faire. Si jamais c'est les données qui sont importante ou bien si c'est les opérations

[Emmanuel Delahaye]

En C existe t'il une méthode de conception pour éviter les problèmes ?

Oui

http://bien-programmer.blogspot.com/

[Lunixinclar]

Données ou fonctions? Les deux, Le C fonctionne aussi en approche objet.
Compiles le plus souvent possible, suis une bonne démarche de programmation, printtf est ton sensei. GTK+ est un bon exemple.

[koala01]

Salut,

Pour ce qui est de la logique purement procédurale (et on se comprend sur le fait que, meme en Orienté Objet, le corps d'une fonciton membre tombe dans ce cas de figure: une suite de choses à faire dans un ordre logique...) la méthode qui est, selon moi, la plus adaptée, et surtout la plus facile à tranfsormer en code par la suite (quel que soit le langage utilisé) est sans doute le =>nassichneiderman<=.

Bien que peu connue, elle présente l'énorme avantage de permettre la représentation logique des boucles et des tests, là où le flowchart se transforme en "plat de spagetti" dés que les boucles et/ou les tests commencent à s'imbriquer.

L'idée générale est de se dire que, hormis les test (de type "vrai faux" ou "à choix multiple") et les boucles, tout n'est jamais "qu'action", meme si on se prévoit la possiblité de représenter les appels à nos fonctions personnalisée de manière différente, et de regrouper ces "actions" dans l'ordre logique d'exéctution au sein d'une "pince" représentant la fonction que l'on crée.

Par exemple, l'algorithme de résolution d'une tour de hannoï en nassichneiderman pourrait ressemler à

Ou celui, non récursif, d'ajout d'un élément en fin de liste pourrait ressembler à

avec, bien entendu, les variables et les types qui vont bien avec

L'une des seules limites, qui vient plus de la difficulté que le programmeur a à s'assurer de la gestion correcte, est ce que l'on appelle la gestion de ruptures.

Mais en préparant le travail avec la méthode jackson et en traduisant le résultat obtenu sous forme de nassichneiderman (ce qui n'est pas bien compliqué), meme la gestion des ruptures devient un jeu d'enfant...

[EDIT] le nassichneiderman présente, en outre, l'avantage de permettre une "traduction automatique" en code (et ce, encore une fois, quel que puisse etre le langage de programmation envisagé), dés le moment où l'on a compris qu'il faut travailler par "colone"[/EDIT]

[Thierry Chappuis]

C'est la première fois que j'entend parler du nassichneiderman. Il faudra que je regarde ça un jour, mais je trouve tout de même l'utilisation de pseudo-code plus lisible pour la description des algorithmes.

Thierry

[koala01]

C'est la première fois que j'entend parler du nassichneiderman. Il faudra que je regarde ça un jour, mais je trouve tout de même l'utilisation de pseudo-code plus lisible pour la description des algorithmes.

Thierry

C'est un avis qui se vaut, si ce n'est que, tant qu'à commencer à écrire du code, pourquoi le faire en "pseudo", et non, directement dans le langage utilisé

A titre perso, je seul avantage que je trouve au pseudo code, c'est qu'il ne nécessite aucun dessin...

Mais, d'un autre coté, une fois que l'on est habitué au nassichneiderman (car, comme toute méthode d'algorithmie, il faut un "temps d'adaptation") il est aussi facile à traduire en code qu'un pseudo code et aussi "parlant" qu'un flowchart, le plat de spagetti en moins...

Tu remarqueras en outre au travers de ces deux exemples choisis que tu retrouves "simplement" sous forme graphique tout ce que tu pourrais retrouver dans un pseudo code

Ceci dit, c'est mon avis perso, et je ne forcerai jamais personne à y adhérer... mais je le partage

[curryfy]

Salut,

Pour ce qui est de la logique purement procédurale (et on se comprend sur le fait que, meme en Orienté Objet, le corps d'une fonciton membre tombe dans ce cas de figure: une suite de choses à faire dans un ordre logique...) la méthode qui est, selon moi, la plus adaptée, et surtout la plus facile à tranfsormer en code par la suite (quel que soit le langage utilisé) est sans doute le =>nassichneiderman<=.

Bien que peu connue, elle présente l'énorme avantage de permettre la représentation logique des boucles et des tests, là où le flowchart se transforme en "plat de spagetti" dés que les boucles et/ou les tests commencent à s'imbriquer.

L'idée générale est de se dire que, hormis les test (de type "vrai faux" ou "à choix multiple") et les boucles, tout n'est jamais "qu'action", meme si on se prévoit la possiblité de représenter les appels à nos fonctions personnalisée de manière différente, et de regrouper ces "actions" dans l'ordre logique d'exéctution au sein d'une "pince" représentant la fonction que l'on crée.

Par exemple, l'algorithme de résolution d'une tour de hannoï en nassichneiderman pourrait ressemler à

Ou celui, non récursif, d'ajout d'un élément en fin de liste pourrait ressembler à

avec, bien entendu, les variables et les types qui vont bien avec

L'une des seules limites, qui vient plus de la difficulté que le programmeur a à s'assurer de la gestion correcte, est ce que l'on appelle la gestion de ruptures.

Mais en préparant le travail avec la méthode jackson et en traduisant le résultat obtenu sous forme de nassichneiderman (ce qui n'est pas bien compliqué), meme la gestion des ruptures devient un jeu d'enfant...

[EDIT] le nassichneiderman présente, en outre, l'avantage de permettre une "traduction automatique" en code (et ce, encore une fois, quel que puisse etre le langage de programmation envisagé), dés le moment où l'on a compris qu'il faut travailler par "colone"[/EDIT]

Merci pour avoir ramené cette représentation des algorithmes particulièrement adapté à la programmation structurée. Je l'utilisais alors que j'étais étudiant en DUT Informatique de Gestion dans les années 95 (j'étais bien le seul d'ailleurs) et je me suis retrouvé comme vous face à l'incrédulité de mes professeurs (sans parler des autres étudiants). J'ai pourtant toujours trouvé cette représentation très efficace. Je l'avais découverte (sous le nom de graph-NS) dans un livre sur la programmation en assembleur 8086 qui présentais cette méthode comme plus efficace qu'un algorigramme et résultant des travaux sur la programmation structurée.