Discussion :

[koala01]

A vrai dire, j'ai été ambulancier dans un service 100 (en Belgique, c'est le numéro d'appel d'urgences) pendant pres de 9 ans...

Et on avait l'habitude de dire qu'il vallait mieux perdre 5 secondes pour passer un carrefour en sécurité plutot que de risquer de ne pas arriver...

Le conseil que je te donne est tiré de la meme veine...

Commence par apprendre ce que le langage attend de toi, avant de t'éparpiller vers des notions qui ne te feront, très souvent, que gagner quelques millièmes de secondes...

Plus tard, quand tu sera familliarisé et que tu pourras estimer que tu maitrise le langage, il sera toujours temps de s'attaquer à des détails... L'important, dans un premier temps, étant de savoir mettre la bonne logique en branle

bonne nuit à toi aussi

[koala01]

Encore une fois, confusion totale. Ce qui fait qu'un programme est performant c'est la qualité de l'algorithme. La vitesse d'horloge, fait simplement que le même algo s'exécutera plus ou moins vite, c'est tout. Ce n'est pas une donnée qui influence la programmation.

C'est effectivement ce que tu as de mieux à faire en ce moment. Garde quand même en tête que la programmation, ce n'est pas la simple maitrise d'un langage. C'est aussi

1 - Savoir définir clairement un problème
2 - Trouver des solutions simples et performantes
3 - Coder proprement, tester son code

Seule la phase 3 concerne la mise en oeuvre d'un langage de programmation.

La phase 2 (conception) est la plus difficile. En plus elle conditionne comlètement le codage. C'est sur ce point qu'il faut acquérir des connaissances et surtout de l'expérience, ainsi que développer son intuition.

+1...

Trop de gens qui estiment "savoir programmer" négligent beaucoup trop la phase de conception (et parfois meme n'arrivent pas à définir clairement un problème...), alors qu'avec un algorithme correctement étudié, l'écriture meme du code se transforme en une sorte de "travail embetant de dactylographie"

[Preez]

D'accord. Et cette phase de conception, elle ne s'apprend pas dans les bouquins je présume? Et avec l'entraînement?
En attendant le K&R2, j'ai trouvé un petit bouquin à moins de 9 Euros avec plein d'exercices et des cours sur les bases, et avec l'epaisseur de l'affaire, ça doit être autrement défini et expliqué que sur internet. Ca me permet de commencer à travailler un peu.
Une dernière fois merci à vous pour tous ces conseils, et a defaut de lire les posts du forum, je viendrai solliciter votre aide le moment venu!

[Emmanuel Delahaye]

D'accord. Et cette phase de conception, elle ne s'apprend pas dans les bouquins je présume?

Pas vraiment, mais il y a quelques principes quand même, comme savoir écrire un algorithme en texte et en pseudo-code.

Je connais mal, mais dans une approche objet, il existe aussi des langages de modélisation comme UML, pour une description formelle des données et des méthodes. Celle-ci débouche sur une sorte de conception automatisée à partir de la spécification détaillée.

Et avec l'entraînement?

Oui, il faut s'appliquer à passer par une phase de conception avant de coder, même pour une simple fonction ou un simple exercice...

[InOCamlWeTrust]

Méfie-toi tout de même des gros pavés sur le langage C... on y trouve beaucoup de fois tout et n'importe quoi !

Concernant l'UML... je trouve que c'est très bien pour faire du Java, mais dans des langages comme Objective Caml, qui possèdent un système de classes très subtil lié à un langage de module très puissant, c'est carrément pas adapté !

[Preez]

Oui, il faut s'appliquer à passer par une phase de conception avant de coder, même pour une simple fonction ou un simple exercice...

D'accord, je retiens!

Méfie-toi tout de même des gros pavés sur le langage C... on y trouve beaucoup de fois tout et n'importe quoi !

Oki! Nan mais il a l'air pas mal ce bouquin (c'est celui la), j'étais pas super enthousiaste en vue de me re-taper toutes la définition des fonctions, des différents types etc. et je voulais passer directement aux pointeurs mais finalement j'ai vu que j'étais passé à côté de pas mal de choses.

[Jean-Marc.Bourguet]

Software tools in Pascal de Kernighan et Plauger (leur Pascal ressemble à une translittération littérale du C).

http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD249.PDF

[koala01]

A vrai dire, la création d'algorithmes, c'est 5 à 10 % de théorie, et 90 à 95% de pratique...

La théorie n'est là que pour te permettre de "te faire une représentation mentale" de quelques concepts aussi abstrait que "qu'est-ce qu'une boucle", "qu'est-ce qu'un test","qu'est-ce qu'une fonction/procedure",et autres ou, typiquement adapté au C, "qu'est-ce qu'un pointeur/un pointeur de pointeur" etc...

Apres la théorie, vient fatalement la pratique... qui n'est qu'une question de "Güde speil und gefund" ("bien joué et trouvé"), où tu envisageras une manière de faire, puis que tu envisagera le fait que "oui, mais si je fais comme cela, j'aurai tel problème, alors que si je fait ainsi, le problème est contourné"

Ainsi, le "simple" probleme de la séparation du jaune d'un oeuf pourrait etre "simplifié", "divisé" en plusieurs problèmes:

• prendre l'oeuf en main sans le casser
• casser la coquille en deux sans l'"éclater completement"
• faire tomber le blanc dans un récipient en gardant le jaune dans les demi coquilles

et chacun de ses problèmes "plus simples" seraient une suite d'instructions à suivre en envisageant, idéalement, les différents cas de figure qui pourraient mal tourner...

Différentes méthodes sont applicables, selon l'importance du projet:

On a déjà parlé de l'UML, qui permet, sur les projets moyens à gros, d'avoir une vue d'ensemble de ce que devra fournir l'application, qui permet de montrer les différentes interactions entre les différents "acteurs" (la personne qui est devant son clavier, l'ordinateur et l'internet/intranet, l'ordinateur et un système de gestion de base de données éventuellement, ...) et de "dégrossir" la logique générale

Il y a aussi le tres connu flowchart, dont, à défaut de t'y etre intéressé, tu as peut etre déjà entendu parler...

Tres efficace dans le cadre d'une conception tournée vers l'assembleur ou le langage machine, il montre cependant de grosses faiblesses en ce qui concerne la représentation de concepts qui existent dans tous les langages de troisième (C, C++ et consors) génération tels que les boucles ou les "tests multiples"...

Et pour notre malheur, les boucles et les tests sont incontournables en programmation.

C'est, sans doute du fait que c'est une des méthodes d'algorithmie les plus connues (pour les petits projets du moins), ce qui justifie que de nombreuses personnes préfèrent s'en passer parce qu'il oblige encore, lorsqu'une boucle est représentée, à réfléchir sur la manière de l'implémenter... alors que, quand un algorithme est correct, toute la réflexion a normalement été effectuée avant d'écrire la première ligne de code (hormis le fait qu'un cas particulier apparaisse alors qu'on n'y avait pas pensé )

Sans compter le fait que, quand il y a beaucoup de boucles ou de tests imbriqués, on finit très vite par se retrouver avec un "plat de spagetti" difficilement compréhensible

Une autre méthode, beaucoup moins connue, et pourtant beaucoup plus efficace à mon gout pour les langages de "troisième génération" est le nassichneiderman qui permet réelleement, si la réflexion a été suffisemment poussée, d'envisager l'écriture du code comme un travail "bete et em" de traduction...

Dans certains cas, la gestion de ruptures (boucles imbriquées "en cascade" ), par exemple, il peut etre intéressant d'utiliser une quatrième méthode qui s'appelle le jackson pour dégrossir le travail.. avant de passer à une méthode plus précise comme le nassichneiderman, par exemple...

Enfin, il y a le pseudo code, également déjà cité, qui n'a, à mon gout, encore une fois, que l'intéret d'etre la seule méthode d'algorithmie à etre purement textuelle... les autres étant plus des "dessins", des shemas...

Son avantage, par contre, c'est qu'il permet d'être plus facilement transmis, sur un forum, par exemple

Comme tu peux le remarquer, chaque technique a ses avantages, ses inconvéniants et ses secteurs de prédilection... Le choix t'appartient bien sur, mais l'idéal est quand meme, à défaut de maitriser toutes ces techniques, de pouvoir passer de l'une à l'autre en fonction de la complexité du projet (il ne sert à rien, par exemple d'utiliser l'UML pour concevoir une application qui te présentera la table de multiplication en mode console ), et du "problème à résoudre"

[Preez]

J'ai vu des livres et tutoriaux traitant de l'UML, mais les autres méthodes que tu cite, je n'en ai jamais entendu parler.
Une question, toutes ces méthodes doivent être "écrites" (j'entends par là couchées sur un bout de papier, tu parle de schéma, de méthode purement textuelle)? Ou ces méthodes sont juste des "manières de raisonner" et des régles, à appliquer dans sa tête?
Par exemple, pour mon remake des lemmings ou mon jeu d'echecs, lorsque le moment viendra:
-un "bon" programmeur, à ma place, définirait un cahier des charges et entrerait dans la programmation en sachant tout ce qu'il y a faire (dans sa tête)
ou
-un "bon" programmeur, à ma place, définirait un cahier des charges, puis écrirait encore toutes les fonctions, les relations entre elles, les boucles etc...
C'est ça que je n'arrive pas à définir, si c'est le première solution, alors il me faudra énormément de temps pour developper une telle logique 'in-my-tête "..

Edit: Jean-Marc, merci pour ton lien, mais c'est quoi cette histoire de Pascal?

[koala01]

Tu peux te contenter de "visualiser" les différentes méthodes dont je parle dans ta tete... mais il faut avouer que c'est beaucoup moins pratique pour en parler ou pour les transformer en code source

Le fait de les avoir sur "support tangible" (sur ton écran ou sur du papier) t'assurera de n'oublier aucune étape du processus...

Un simple exemple: si, sans une boucle, tu oublies de passer à l'élément suivant qu'il faut gérer, tu n'en sortira jamais

Je n'ai qu'un souvenir tres vague de ce qu'était le jeu lemmings, mais, en gros, un "bon programmeur" fera le cahier des charges, séparera les différentes parties du jeu (la gestion des "cartes du niveau", la gestion des "méchants et de leur IA", la gestion du joueur, des scores, j'en passe et des sans doute meilleurs) en autant de "modules" que nécessaires et "couchera sur papier" les différentes interactions entre ces modules: la carte t'empechera d'aller à certains endroits, te donnera peut etre des "bonus", et, une fois arrivé à un point donné de la carte, il faudra sans doute en charger une autre,le méchant est susceptible de te tuer, mais tu peux peux aussi le tuer et gagner des points/des bonus, le méchant peut, peut etre, se déplacer sur la carte...sont autant d'interactions d'un module sur l'autre

Les usecases de l'UML, entre autres, te viendront sans doute bien en aide dans cette étape

Puis, il s'attaquera pour chaque "module", à déterminer les grosses étapes d'utilisation, et la logique à suivre pour chacune de ces étapes... En se basant sur ce qu'il a déjà fait en début de conception, et en y retournant éventuellement s'il s'appercoit qu'il a oublié d'envisager un cas spécifique

Là encore, un "bon programmeur" couchera le résultat de sa réflexion sur papier

A la fin, le "bon programmeur" aura sans doute une farde remplie de paprasse, ou peut etre un dossier sur son ordinateur, contenant le cahier des charges, l'étude (générale)des différents modules, l'étude des interactions entre les différents modules, l'étude approfondie des différents module (toutes les fonctions et procédures que chaque module fournit) et un algorithme détaillé de la logique à suivre pour chaque fonction et procédure de chaque module...

Ce ne *devrait etre* (idéalement) qu'au moment où le "bon programmeur" aura au minimum un "premier jet" de tout cela qu'il commencera à écrire ses premières lignes de code.

Evidemment, si certaines étapes doivent etre envisagées avant d'autres, elles ne sont pas "figées" dans un ordre particulier...

Si, à n'importe quel moment, tu te dis que "en somme, je voudrais permettre le jeu en réseau", par exemple, il faudra sans doute reprendre à partir du cahier des charges...

Si, à un moment, tu te dit "en somme, tel module a besoin de telle fonction pour faciliter le travail par la suite", il faudra l'inclure dans l'étude approfondie du module en question, et en créer l'algorithme...

Si, alors que tu es occupé à créer le code source d'une fonction, tu te rend compte que, betement, tu as oublié de prendre "le cas particulier qui n'arrive que tous les 108 ans" en compte, mais que ce cas particulier implique de revoir toute la logique de cette fonction, il faudra réécrire l'algorithme en le prenant en compte

Les cas sont multiples et variés, bien sur, et ce ne sont que des exemples

Dans la liste des cas qui nécessitent une remise en question d'une partie du travail effectué, on peut aussi citer la découverte d'une bibliotheque qui, justement, facilite tel ou tel traitement

Pour ce qui est de la théorie générale de la programmation, le flowchart et le nassichneiderman, tu en trouvera une bonne partie (à titre d'initiation) sur =>Mon site<= (certaines parties sont encore en constructions )

[Preez]

D'accord, je comprends mieux cette "phase de conception" et son importance pour la réussite du programme.
Merci pour ton site, j'étais déjà passé dessus, mais je n'avais pas vu les cours sur le flowchart et le nassichneiderman (en voilà des jolis noms!).
Et bien, c'est bien plus compliqué qu'il n'y paraît que de programmer un remake des lemmings (les lemmings et un jeu bien "prise de tête", on dispose d'un nombre données de lemmings au départ, ces lemmings sont des petits rongeurs qui avancent toujours dans le même sens et qui font tout ce qu'on leur dit, on peut leur faire fabriquer un escalier, les équiper d'un parachute, les faire creuser, et le but du jeu et de faire arriver un certain pourcentage de lemmings vivant à l'autre bout de la map, j'y ai passé des heures...).

[koala01]

A vrai dire, le moment où l'on perd le plus de temps si on n'a pas un support "papier", ce n'est pas la conception... Ni meme l'écriture du code (je l'ai déjà dit, ce n'est qu'un travail de pur traduction à partir du moment où tu sais quelle logique suivre)...

C'est lorsque, pour la premiere fois, tu cliques sur le fameux bouton "construire et exécuter"... et l'étape qui s'en suit...

Je ne parle pas des erreurs de syntaxe, comme l'oubli malheureux d'un ;d'une virgule ou d'un espace... je parle du "debuggage" proprement dit où tu risque de te casser la tete très longtemps sur une question qui ressemblera immancablement à "mais pourquoi il ne fait pas ce que je veux"...

Tout cela, parce que, l'erreur étant humaine, peut etre pressé d'essayer une premiere fois ton application, tu auras oublié un test essentiel ou une incrémentation ou...(finalement, ca peut etre beaucoup de choses )

Au final, le temps que tu auras "gagné" à ne pas te faire un support "papier", tu le perdras sans doute 10 ou 20 fois avant de te rendre compte que "mais bete type, j'ai oublié un i++ ...", alors que, avec un support papier, tu l'aurais sans doute remarqué en moins de trente secondes...

Mieux, meme: il y a fort à parier que, avec un algorithme suffisemment détaillé, ton programme réagisse exactement de la manière dont tu l'avais prévu à la premiere compilation sans erreur (AKA: une fois que tu auras corrigé les erreurs de syntaxe)

S'il subsiste des erreurs, ce sera parfois parce que tu n'a pas poussé la logique assez loin, parfois, simplement, parce que lors du codage, tu n'a pas pris en compte le fait que tu disposes d'un pointeur que tu essaie d'utiliser comme simple variable, ou vice versa...

*Peut etre* estimeras tu que "telle ou telle partie est trop lente", et donc, qu'il faut *peut etre* remettre la logique en question, mais le programme sera malgré tout fonctionel

Et tout ca, c'est encore sans meme envisager le fait que, peut etre, lors de l'écriture du premier cahier des charges, tu puisse te rendre compte de l'énormité du projet, décider de t'encadrer d'une équipe, et qu'il faut avant tout que cette équipe soit en mesure de communiquer... Au quel cas, un support "papier" devient presque indispensable