J’ai eu un exam il y a peu et je devais faire un petit prog en xhtml et php et je suis sur a 100% que si je le testais sur pc impossible de le lancer un point virgule quelque part ou une parenthese et hop c’est foutu.
Et pourtant il ne faisait qu’une petite 100taines de lignes. C’est vraiment un petit prog 
d’où l’interet de l’analyse top-down et du pseudo-langage / pseudo-code …
J’y peux rien si la prog c’est pas mon truc 
[quote=“Ashgenesis”]Tout a fait d’accord avec toi usinagaz c’est d’ailleurs pour ca que ca me fait rire les profs qui nous font faire des programmes sur feuilles sans docs et sans acces a un pc ou a un quelconque manuel 
C’est plutot galere mais bon faut s’y faire[/quote]
Ah, je l’attendais celle là, eh bien oui, je fais des tas de programmes en direct au tableau sans vidéoprojecteur en expliquant à haute voix comment je conçois le programme, comment la structure de données donne un squelette quasi automatique de fonction (on est en Caml, n’oublions pas), et bien sûr je demande aussi pourquoi le programme que j’ai écris plante, quel effet de bord a la dite fonction… Pour ce qui est du manuel dans ce cas là, c’est moi ou les élèves. J’ai régulièrement parié avec les élèves que les programmes écrits en cours ne comportaient pas de bugs, erreurs élémentaires de syntaxe exceptées (genre + au lieu de +.) -il faut dire que je fais le cours sans note ni bouquin et les programmes sont donc improvisés- le fait que j’ai toujours gagné ces paris montre bien la fiabilité des méthodes. Les programmes peuvent faire jusqu’à 2 tableaux à 3 pans mais il ne faut pas être trop rébarbatif. Ces programmes aux tableaux n’ont aucun intérêt en eux mêmes, c’est la façon dont on les conçoit qui est intéressante, se pointer avec un portable et montrer le beau programme que je suis capable de faire sera amusant pour les élèves (surtout si je met de la déco) mais absolument sans aucun intérêt!
Les erreurs élémentaires de syntaxe ne compte absolument pas dans l’évaluation d’un programme à un examen sauf si il y en a plus de 60 par ligne…
c’est clair Ash, le moindre point virgule, le moindre guillemet …
mais bon, je suis sur qu’on te demandais pas que ça tourne en fait, mais que ça puisse tourner …
moi mon script, je pensais avoir presque fini, et non, il a fallu que je m’enbarque au dernier moment (tout allait rouler) dans des fonctions de mises en forme pour faire plus zoli … bonjour la gestion des strings en bash, et les paramètres de fonctions, getopts et tout, ça me convenait pas ça non plus, j’en ai fait une autre de getopts, (3 versions completement différentes) , aie aie aie ( en fait c’est 1000 lignes par ex., mais ya les 3/4 c’est des fonctions que je réutiliserais pour autre chose, genre les tableaux, les chaines, l’affichage, la lecture … )
[quote=“neness”]ça fonctionne merci mais le coups du :
while ( (c = getchar()) != ‘\n’ && c != EOF );
pas très bien saisi l’utilité en + c long pour apprendre par coeur ça le fais pas trop !
[/quote]
Pour comprendre, fais ce test :
[code]#include <stdio.h>
int main()
{
int c;
c = getchar(); /* ici tape ab + entrée */
printf("%c\n", c);
c = getchar();
printf("%c\n", c);
return 0;
}
[/code]
getchar() lit un caractère sur l’entrée standard (après l’appuie de la touche entrée, comme scanf()). Tu remarqueras que après que tu aies tapé ab [entrée], le programme affiche :
a
b
et se termine, au lieu d’afficher a et d’attendre une autre saisie comme on aimerait que ça se passe.
Pourquoi ? Parce le premier getchar() ne ‘prend’ que le a. Il reste donc b et \n (entrée) sur l’entrée standard (stdin). D’où le :
do {
c = getchar();
} while (c != '\n');
( équivalent de while ( (c = getchar()) != ‘\n’) ; en plus compréhensible. )
à rajouter après les getchar(), pour digérer les caractères inutiles. Le EOF c’est pour la fin de fichier, c’est pour si jamais tu tapes Ctrl + D pour que ça puisse terminer, mais tu peux t’en passer.
Tu peux en faire une fonction pour éviter de tout taper à chaque fois.
[quote=“fran.b”][quote=“Ashgenesis”]Tout a fait d’accord avec toi usinagaz c’est d’ailleurs pour ca que ca me fait rire les profs qui nous font faire des programmes sur feuilles sans docs et sans acces a un pc ou a un quelconque manuel
C’est plutot galere mais bon faut s’y faire[/quote]
Ah, je l’attendais celle là, eh bien oui, je fais des tas de programmes en direct au tableau sans vidéoprojecteur en expliquant à haute voix comment je conçois le programme, comment la structure de données donne un squelette quasi automatique de fonction (on est en Caml, n’oublions pas), et bien sûr je demande aussi pourquoi le programme que j’ai écris plante, quel effet de bord a la dite fonction… Pour ce qui est du manuel dans ce cas là, c’est moi ou les élèves. J’ai régulièrement parié avec les élèves que les programmes écrits en cours ne comportaient pas de bugs, erreurs élémentaires de syntaxe exceptées (genre + au lieu de +.) -il faut dire que je fais le cours sans note ni bouquin et les programmes sont donc improvisés- le fait que j’ai toujours gagné ces paris montre bien la fiabilité des méthodes. Les programmes peuvent faire jusqu’à 2 tableaux à 3 pans mais il ne faut pas être trop rébarbatif. Ces programmes aux tableaux n’ont aucun intérêt en eux mêmes, c’est la façon dont on les conçoit qui est intéressante, se pointer avec un portable et montrer le beau programme que je suis capable de faire sera amusant pour les élèves (surtout si je met de la déco) mais absolument sans aucun intérêt!
Les erreurs élémentaires de syntaxe ne compte absolument pas dans l’évaluation d’un programme à un examen sauf si il y en a plus de 60 par ligne…[/quote]Je comprends mieux l’intérêt mais quelques fois c’est plutôt hardu quand tu dois te souvenir d’une fonction que tu dois utiliser pour ledit programme sans te souvenir par exemple de l’ordre des arguments a utiliser ou tout simplement te souvenir de telle ou telle fonction a utiliser. C’est dans ce cas l’utilisation du manuel qui peut aider. Si l’on ne compte pas les erreurs de syntaxe alors ca devrais aller
L’ordre des arguments est en général assez intuitif et au besoin je demande aux élèves si j’ai un doute, le nom des fonctions comme le nom des variables doit être explicite. Un code clair est un code ou les variables s’appelle reste_de_la_liste, pivot, sommet_reference et non lr, p, O. Avec ce genre de choses on n’a pas de souci et les programmes n’ont besoin que de peu de commentaires.
[edit: si je suivais les conseils que je donne, ce serait un bonheur 
)
Là je ne peux etre que d’accord Mais je parle surtout de ce genre de développement de prog lors d’un examen, en cours avec l’aide du prof et/ou des élèves c’est légèrement différent, un trou de mémoire peut etre comblé par quelqu’un d’autre en exam c’est une panne seche et la c’est moins evident.
Je viens d’aller voir si j’avais reussi mon exam (2nd session) et je m’aperçois que je l’ai effectivement réussi avec un petit 14/20 (pouvais mieux faire je sais)
Ceci dit je pense que l’on aurais plutot intéret a faire faire de l’algo aux élèves plutot que directement le programme ca leur permetterais d’éviter de coder salement, meme si certains langages oblige un code propres
Mouais, j’irais un peu plus loin que fran, et je dirais que la méthode d’approche et de résolution d’un problême est souvent plus interessantes AMA que la resolution du problême lui même.
Enfin j’me comprends. 
extrait de Documentation/CodingStyle (noyau Linux) :
[quote]C is a Spartan language, and so should your naming be. Unlike Modula-2 and Pascal programmers, C programmers do not use cute names like ThisVariableIsATemporaryCounter. A C programmer would call that variable “tmp”, which is much easier to write, and not the least more difficult to understand.
[…]
If you are afraid to mix up your local variable names, you have another problem, which is called the function-growth-hormone-imbalance syndrome. See next chapter.[/quote]
Note : j’essaie de faire de l’humour là, bien entendue il faut faire la part des choses.
Ben, je passe mon temps à lire des programmes écrits par d’autres, à les comprendre et à tester leur validité. Un programme avec des petits noms même avec commentaire est beaucoup moins compréhensible qu’un programme avec des noms de fonctions et de variables explicites sans commentaires. Dans l’exemple donné «temporaire» est un bon nom, et «tmp» est compréhensible si le contexte le permet. Par ailleurs le coding style est destiné à des programmeurs avertis, pas des débutants…
J’ai oublié de dire (ça m’a empêché de dormir), que dans le cas du programme de neness, si on ne vide pas le buffer clavier, ça marchera quand même, parce que scanf() saute les espaces et les sauts de ligne.
Mais d’une façon générale, il est bon de vider le buffer.