Prog pour calculer des racines carré

[Sacles]

Bonjour,

 

Faudrait y aller mollo, c'est son tout premier programme en C

Ce n'est évidemment pas une critique mais c'était simplement pour signaler qu'envisager tous les cas de figure est une des difficultés de la programmation.

 

Dans le cas contraire, le programme plante ou donne des résultats erronés.

 

Tester un programme peut, éventuellement, montrer qu'il ne marche pas, jamais prouver qu'il est correct, c'est à dire que, dans tous les cas possibles, il conduit l'exécutant (la machine) à mener à bien la tâche proposée au départ.

 

Programmer, c'est passer de son savoir-faire une tâche au savoir la faire-faire par un autre (la machine). Si l'homme peut réagir à des cas imprévus, la machine est incapable de le faire.

 

Avant d'écrire la 1re ligne d'un programme, il est nécessaire de savoir précisément ce que l'on va faire faire par la machine. Le "Quoi faire?" est l'étape primordiale d'un programme.

 

Quoi faire (description précise)? >>> Comment faire (stratégies)? >>> Comment faire faire (rédaction de la marche à suivre, du programme)?

 

"Solving a problem gives you the solution. Knowing how you solved the problem gives you a program" M. JAMES dans "Elegant Programming".

 

Programmer c'est beaucoup plus que la connaissance du langage de programmation employé qui est "simplement" le "Comment dire (les choses à faire faire par la machine)?" La dernière étape de la programmation.

 

Bon dimanche à tous.

Modifié le 14 octobre 2007 par Sacles

[KewlCat]

Certes.

Là, on aborde un sujet qui est d'ordre général et qui devrait être "épinglé". Les règles permettant de programmer de manière élégante, efficace et "maintenable" ne sont (malheureusement) pas qu'à donner aux programmeurs débutants !

[Sacles]

Re,

 

Même à partir d'exercices simples (comme celui envisagé par Ryuuzaki), on peut prendre de bonnes habitudes de programmation.

 

Dans le cas contraire, on arrive vite dans le bidouillage et le rafistolage où les programmes sont adaptés au fur et à mesure de la découverte des problèmes qui n'avaient pas été envisagés au départ.

 

La connaissance des structures de programmation est tout aussi importante que la connaissance du langage.

 

Tout programme est constitué de combinaison d'au plus 4 (5) types de structure:

 

1.- La séquence

2.- La répétition (2 types)

3.- L'alternative

4.- L' appel de procédure

[5.- Le branchement]

 

Salut.

Modifié le 14 octobre 2007 par Sacles

[KewlCat]

La connaissance des structures de programmation est tout aussi importante que la connaissance du langage.

Ouais, mais c'est surtout la phase avant la programmation proprement dite qu'il ne faut surtout pas négliger (voire carrément oublier !) : établir les besoins, analyser fonctionnellement et spécifier ce que doit faire le programme.

Problème : si on n'a jamais fait de programmation on n'est pas capable de dire quels sont les outils à disposition et il devient alors impossible de faire une analyse qui se tienne (hormis des bribes du style "y'a qu'à .... suffit de ..." sans aucun appui sur des éléments réels...). C'est facile de faire des spécifications farfelues où tout "se tient" mais où la mise en pratique est un enfer. S'il n'y a pas connaissance préalable de l'outil (par formation ou par bidouillage) comment peut-on articuler un programme qui se tient ? Comment peut-on penser construire une application viable si on ne connaît pas les briques de base ?

Quiconque sait écrire des programmes "proprement" en COBOL va cribler un programme qu'il a à faire en C de "goto" et va coller l'intégralité du code dans une unique classe s'il fait du Java, s'il n'a jamais travaillé avec ces langages !!

 

La théorie c'est très bien, mais tant qu'on n'a pas mis les mains dans le cambouis il est impossible d'analyser un problème de la façon qui colle au mieux à ce que le langage sait faire... La théorie doit s'appuyer sur un certain niveau de pratique !

(... sinon c'est comme ça qu'on se retrouve comme un con à avoir commandé une nouvelle appli de gestion en C# (ou en PowerBuilder, si on n'a pas eu la visite de nos amis de Microsoft), dépensé des centaines de milliers d'euros, vu passer des dizaines d'intervenants, experts, consultants, branleurs affublés de titres usurpés ou de diplômes extorqués, pour tout jeter au bout de cinq ans de développement parce que les specs ont été écrites par des gens qui n'avaient pas la moindre idée de la façon de fonctionner de cet outil !)

 

La phase de "bidouillage" est, à mon avis, une bonne entrée en matière pour se familiariser avec l'outil. Il faut juste éviter de partir sur cette base de "bidouillage" pour construire quelque chose de sérieux.

 

D'abord faire connaissance, ensuite voir comment construire quelque chose de solide. Partir sans rien connaître c'est du suicide. Partir en se disant "je vais improviser" est guère mieux.

[Sacles]

Bonjour,

 

La théorie c'est très bien, mais tant qu'on n'a pas mis les mains dans le cambouis il est impossible d'analyser un problème de la façon qui colle au mieux à ce que le langage sait faire... La théorie doit s'appuyer sur un certain niveau de pratique !

Tout à fait d'accord, c'est pourquoi, à mon avis, les deux (théorie et pratique) doivent aller de pair.

 

Quiconque sait écrire des programmes "proprement" en COBOL va cribler un programme qu'il a à faire en C de "goto"[...]

Les fameux plats de spaghettis :P.

 

Bonne semaine.

[Dylav]

Quiconque sait écrire des programmes "proprement" en COBOL va cribler un programme qu'il a à faire en C de "goto"

Les fameux plats de spaghettis

Messieurs, vous caricaturez. J'espère que c'est volontaire...

 

N'avez-vous jamais entendu parler de programmation structurée (séquence d'introduction, séquence de clôture, séquence itérative de traitement, comprenant elle-même une séquence d'introduction, une séquence de clôture, une séquence itérative de traitement, etc.) ? Je pense être encore capable de vous construire, sur n'importe quel problème, un programme Cobol sans un seul GO TO (mais est-ce vraiment un but incontournable ?)...

 

Pour moi, peu importe le langage, l'analyse est toujours la même, c'est celle de Descartes (je résume), diviser chaque problème en sous-problèmes plus simples, donc plus faciles à résoudre. Après, peu importe que l'on débouche sur de la programmation classique (bien entendu structurée) ou de la programmation objet (c'est effectivement intellectuellement extrêmement élégant, de rassembler l'objet et ses comportements, ou méthodes)...

[KewlCat]

Oui, c'est vrai qu'il n'y a pas que GOTO et qu'il existe aussi PERFORM, mais c'était pour donner une idée (déjà que j'en avais collé une grosse tartine...)

[Sacles]

Re,

 

Messieurs, vous caricaturez. J'espère que c'est volontaire...

Non, non, mais cela ne s'applique évidemment pas à tous les programmeurs mais avouons que ce GO TO rendait les programmes de certains illisibles.

 

N'avez-vous jamais entendu parler de programmation structurée (séquence d'introduction, séquence de clôture, séquence itérative de traitement, comprenant elle-même une séquence d'introduction, une séquence de clôture, une séquence itérative de traitement, etc.) ?

Tout à fait d'accord. Voir mon message sur les structures de programmation (où j'ai eu soin de mettre le branchement entre crochets).

 

Salut.

Modifié le 15 octobre 2007 par Sacles

[Dylav]

Oui, les plats de spaghettis, c'était dans les années 60, lorsque les programmeurs étaient des autodidactes pris pour des magiciens par des patrons qui les surpayaient... La situation n'était déjà plus la même dans les années 70 et surtout 80, où la rigueur, y compris budgétaire, commença à frapper ! Et ce ne fut pas un mal pour la profession, à mon avis

[KewlCat]

les plats de spaghettis, c'était dans les années 60

Euh....

Comment dire....

 

Tu veux que je te donne la dernière date à laquelle j'ai croisé un "plat de spaghettis" ? (et je dis bien "dernière", parce que si je te les donne toutes je vais déclencher un buffer overflow sur le forum)

Certes, en Objet on a du mal à faire des GOTO, mais y'a nettement plus tordu pour programmer "comme en BASIC" avec du Java...