In article ,
Marc Boyer wrote:Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Si tu autorises les gens a prendre des habitudes differentes "parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
In article <slrngodgcn.396.Marc.Boyer@gavarnie.cert.fr>,
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> wrote:
Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Si tu autorises les gens a prendre des habitudes differentes "parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
In article ,
Marc Boyer wrote:Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Si tu autorises les gens a prendre des habitudes differentes "parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Michael DOUBEZ writes:Marc Espie wrote:In article ,
Marc Boyer wrote:Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Une bonne partie de l'informatique, c'est cense etre faire des choses
qui marchent de facon previsible.
99% de ce qu'on fait est debile, c'est le 1% restant qui presente
de l'interet.
Il faut s'arranger pour que les 99% soient les plus simples possibles,
de facon mecanique, ce qui veut dire prendre des automatismes corrects.
(comme presenter son code toujours de la meme facon, verifier les appels
systemes qui peuvent echouer, ne pas laisser passer de warnings a la
compilation).
Si tu autorises les gens a prendre des habitudes differentes "parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Un TP est un temps limité. Je comprends qu'il soit souhaitable de se
concentrer sur les objectifs du TP plutôt que de passer du temps sur
l'aspect qualité (qui est une mesure assez vague). En plus, le message est
plus clair si il n'est pas parasité par des considérations secondes par
rapport à ce qui doit être démontré.
Si dans les TP on ne voit pas les bonnes pratiques, on prend beaucoup trop
de mauvaises habitudes.
Michael DOUBEZ <michael.doubez@free.fr> writes:
Marc Espie wrote:
In article <slrngodgcn.396.Marc.Boyer@gavarnie.cert.fr>,
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> wrote:
Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Une bonne partie de l'informatique, c'est cense etre faire des choses
qui marchent de facon previsible.
99% de ce qu'on fait est debile, c'est le 1% restant qui presente
de l'interet.
Il faut s'arranger pour que les 99% soient les plus simples possibles,
de facon mecanique, ce qui veut dire prendre des automatismes corrects.
(comme presenter son code toujours de la meme facon, verifier les appels
systemes qui peuvent echouer, ne pas laisser passer de warnings a la
compilation).
Si tu autorises les gens a prendre des habitudes differentes "parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Un TP est un temps limité. Je comprends qu'il soit souhaitable de se
concentrer sur les objectifs du TP plutôt que de passer du temps sur
l'aspect qualité (qui est une mesure assez vague). En plus, le message est
plus clair si il n'est pas parasité par des considérations secondes par
rapport à ce qui doit être démontré.
Si dans les TP on ne voit pas les bonnes pratiques, on prend beaucoup trop
de mauvaises habitudes.
Michael DOUBEZ writes:Marc Espie wrote:In article ,
Marc Boyer wrote:Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Une bonne partie de l'informatique, c'est cense etre faire des choses
qui marchent de facon previsible.
99% de ce qu'on fait est debile, c'est le 1% restant qui presente
de l'interet.
Il faut s'arranger pour que les 99% soient les plus simples possibles,
de facon mecanique, ce qui veut dire prendre des automatismes corrects.
(comme presenter son code toujours de la meme facon, verifier les appels
systemes qui peuvent echouer, ne pas laisser passer de warnings a la
compilation).
Si tu autorises les gens a prendre des habitudes differentes "parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Un TP est un temps limité. Je comprends qu'il soit souhaitable de se
concentrer sur les objectifs du TP plutôt que de passer du temps sur
l'aspect qualité (qui est une mesure assez vague). En plus, le message est
plus clair si il n'est pas parasité par des considérations secondes par
rapport à ce qui doit être démontré.
Si dans les TP on ne voit pas les bonnes pratiques, on prend beaucoup trop
de mauvaises habitudes.
Michael DOUBEZ writes:Un TP est un temps limité. Je comprends qu'il soit souhaitable de se
concentrer sur les objectifs du TP plutôt que de passer du temps sur
l'aspect qualité (qui est une mesure assez vague). En plus, le message est
plus clair si il n'est pas parasité par des considérations secondes par
rapport à ce qui doit être démontré.
Si dans les TP on ne voit pas les bonnes pratiques, on prend beaucoup trop
de mauvaises habitudes.
(Personnellement, j'avais pris le texte de Marc Boyer comme de l'ironie).
Michael DOUBEZ <michael.doubez@free.fr> writes:
Un TP est un temps limité. Je comprends qu'il soit souhaitable de se
concentrer sur les objectifs du TP plutôt que de passer du temps sur
l'aspect qualité (qui est une mesure assez vague). En plus, le message est
plus clair si il n'est pas parasité par des considérations secondes par
rapport à ce qui doit être démontré.
Si dans les TP on ne voit pas les bonnes pratiques, on prend beaucoup trop
de mauvaises habitudes.
(Personnellement, j'avais pris le texte de Marc Boyer comme de l'ironie).
Michael DOUBEZ writes:Un TP est un temps limité. Je comprends qu'il soit souhaitable de se
concentrer sur les objectifs du TP plutôt que de passer du temps sur
l'aspect qualité (qui est une mesure assez vague). En plus, le message est
plus clair si il n'est pas parasité par des considérations secondes par
rapport à ce qui doit être démontré.
Si dans les TP on ne voit pas les bonnes pratiques, on prend beaucoup trop
de mauvaises habitudes.
(Personnellement, j'avais pris le texte de Marc Boyer comme de l'ironie).
Marc Espie wrote:In article ,
Marc Boyer wrote:Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Une bonne partie de l'informatique, c'est cense etre faire des choses
qui marchent de facon previsible.
99% de ce qu'on fait est debile, c'est le 1% restant qui presente
de l'interet.
Il faut s'arranger pour que les 99% soient les plus simples possibles,
de facon mecanique, ce qui veut dire prendre des automatismes corrects.
(comme presenter son code toujours de la meme facon, verifier les appels
systemes qui peuvent echouer, ne pas laisser passer de warnings a la
compilation).
Si tu autorises les gens a prendre des habitudes differentes "parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Un TP est un temps limité. Je comprends qu'il soit souhaitable de se
concentrer sur les objectifs du TP plutôt que de passer du temps sur
l'aspect qualité (qui est une mesure assez vague). En plus, le message
est plus clair si il n'est pas parasité par des considérations secondes
par rapport à ce qui doit être démontré.
Je ne vois pas l'interet de s'encombrer la tete avec plusieurs facons
de faire du code. On s'en prend une qui est correcte et on s'y tient.
Les aficionados de PERL vont faire une attaque. :)
Marc Espie wrote:
In article <slrngodgcn.396.Marc.Boyer@gavarnie.cert.fr>,
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> wrote:
Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Une bonne partie de l'informatique, c'est cense etre faire des choses
qui marchent de facon previsible.
99% de ce qu'on fait est debile, c'est le 1% restant qui presente
de l'interet.
Il faut s'arranger pour que les 99% soient les plus simples possibles,
de facon mecanique, ce qui veut dire prendre des automatismes corrects.
(comme presenter son code toujours de la meme facon, verifier les appels
systemes qui peuvent echouer, ne pas laisser passer de warnings a la
compilation).
Si tu autorises les gens a prendre des habitudes differentes "parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Un TP est un temps limité. Je comprends qu'il soit souhaitable de se
concentrer sur les objectifs du TP plutôt que de passer du temps sur
l'aspect qualité (qui est une mesure assez vague). En plus, le message
est plus clair si il n'est pas parasité par des considérations secondes
par rapport à ce qui doit être démontré.
Je ne vois pas l'interet de s'encombrer la tete avec plusieurs facons
de faire du code. On s'en prend une qui est correcte et on s'y tient.
Les aficionados de PERL vont faire une attaque. :)
Marc Espie wrote:In article ,
Marc Boyer wrote:Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Une bonne partie de l'informatique, c'est cense etre faire des choses
qui marchent de facon previsible.
99% de ce qu'on fait est debile, c'est le 1% restant qui presente
de l'interet.
Il faut s'arranger pour que les 99% soient les plus simples possibles,
de facon mecanique, ce qui veut dire prendre des automatismes corrects.
(comme presenter son code toujours de la meme facon, verifier les appels
systemes qui peuvent echouer, ne pas laisser passer de warnings a la
compilation).
Si tu autorises les gens a prendre des habitudes differentes "parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Un TP est un temps limité. Je comprends qu'il soit souhaitable de se
concentrer sur les objectifs du TP plutôt que de passer du temps sur
l'aspect qualité (qui est une mesure assez vague). En plus, le message
est plus clair si il n'est pas parasité par des considérations secondes
par rapport à ce qui doit être démontré.
Je ne vois pas l'interet de s'encombrer la tete avec plusieurs facons
de faire du code. On s'en prend une qui est correcte et on s'y tient.
Les aficionados de PERL vont faire une attaque. :)
Marc Espie wrote:In article ,
Marc Boyer wrote:Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Une bonne partie de l'informatique, c'est cense etre faire des choses
qui marchent de facon previsible.
99% de ce qu'on fait est debile, c'est le 1% restant qui presente
de l'interet.
Il faut s'arranger pour que les 99% soient les plus simples possibles,
de facon mecanique, ce qui veut dire prendre des automatismes corrects.
(comme presenter son code toujours de la meme facon, verifier les appels
systemes qui peuvent echouer, ne pas laisser passer de warnings a la
compilation).
Si tu autorises les gens a prendre des habitudes differentes "parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Un TP est un temps limité. Je comprends qu'il soit souhaitable de se
concentrer sur les objectifs du TP plutôt que de passer du temps sur
l'aspect qualité (qui est une mesure assez vague). En plus, le message
est plus clair si il n'est pas parasité par des considérations secondes
par rapport à ce qui doit être démontré.
Je ne vois pas l'interet de s'encombrer la tete avec plusieurs facons
de faire du code. On s'en prend une qui est correcte et on s'y tient.
Les aficionados de PERL vont faire une attaque. :)
Marc Espie wrote:
In article <slrngodgcn.396.Marc.Boyer@gavarnie.cert.fr>,
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> wrote:
Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Une bonne partie de l'informatique, c'est cense etre faire des choses
qui marchent de facon previsible.
99% de ce qu'on fait est debile, c'est le 1% restant qui presente
de l'interet.
Il faut s'arranger pour que les 99% soient les plus simples possibles,
de facon mecanique, ce qui veut dire prendre des automatismes corrects.
(comme presenter son code toujours de la meme facon, verifier les appels
systemes qui peuvent echouer, ne pas laisser passer de warnings a la
compilation).
Si tu autorises les gens a prendre des habitudes differentes "parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Un TP est un temps limité. Je comprends qu'il soit souhaitable de se
concentrer sur les objectifs du TP plutôt que de passer du temps sur
l'aspect qualité (qui est une mesure assez vague). En plus, le message
est plus clair si il n'est pas parasité par des considérations secondes
par rapport à ce qui doit être démontré.
Je ne vois pas l'interet de s'encombrer la tete avec plusieurs facons
de faire du code. On s'en prend une qui est correcte et on s'y tient.
Les aficionados de PERL vont faire une attaque. :)
Marc Espie wrote:In article ,
Marc Boyer wrote:Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Une bonne partie de l'informatique, c'est cense etre faire des choses
qui marchent de facon previsible.
99% de ce qu'on fait est debile, c'est le 1% restant qui presente
de l'interet.
Il faut s'arranger pour que les 99% soient les plus simples possibles,
de facon mecanique, ce qui veut dire prendre des automatismes corrects.
(comme presenter son code toujours de la meme facon, verifier les appels
systemes qui peuvent echouer, ne pas laisser passer de warnings a la
compilation).
Si tu autorises les gens a prendre des habitudes differentes "parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Un TP est un temps limité. Je comprends qu'il soit souhaitable de se
concentrer sur les objectifs du TP plutôt que de passer du temps sur
l'aspect qualité (qui est une mesure assez vague). En plus, le message
est plus clair si il n'est pas parasité par des considérations secondes
par rapport à ce qui doit être démontré.
Je ne vois pas l'interet de s'encombrer la tete avec plusieurs facons
de faire du code. On s'en prend une qui est correcte et on s'y tient.
Les aficionados de PERL vont faire une attaque. :)
On 2009-02-02, Marc Espie wrote:In article ,
Marc Boyer wrote:Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Je pense que tu as mal compris mon propos.Si tu autorises les gens a prendre des habitudes differentes "parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Je n'autorise pas ce genre de chose. Simplement, quand tu énonces
une règles "genre, les variables partagées, c'est mal", et que les
étudiants voient dans leur pratique (TP) qu'en fait, ça leur
simplifie la vie (ce qui est vrai), il faut expliquer la différence
de contexte.
Un étudiant a souvent du mal à réaliser que ce qu'il prend
pour un gros projet (5000 LOC, 240h de travail) ne représente
pas grand chose au niveau industriel, et que les règles qu'on
présente sont là pour gérer des problèmes qui ne se posent
pas sur d'aussi petit projets.
Marc Boyer
On 2009-02-02, Marc Espie <espie@lain.home> wrote:
In article <slrngodgcn.396.Marc.Boyer@gavarnie.cert.fr>,
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> wrote:
Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Je pense que tu as mal compris mon propos.
Si tu autorises les gens a prendre des habitudes differentes "parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Je n'autorise pas ce genre de chose. Simplement, quand tu énonces
une règles "genre, les variables partagées, c'est mal", et que les
étudiants voient dans leur pratique (TP) qu'en fait, ça leur
simplifie la vie (ce qui est vrai), il faut expliquer la différence
de contexte.
Un étudiant a souvent du mal à réaliser que ce qu'il prend
pour un gros projet (5000 LOC, 240h de travail) ne représente
pas grand chose au niveau industriel, et que les règles qu'on
présente sont là pour gérer des problèmes qui ne se posent
pas sur d'aussi petit projets.
Marc Boyer
On 2009-02-02, Marc Espie wrote:In article ,
Marc Boyer wrote:Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Je pense que tu as mal compris mon propos.Si tu autorises les gens a prendre des habitudes differentes "parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Je n'autorise pas ce genre de chose. Simplement, quand tu énonces
une règles "genre, les variables partagées, c'est mal", et que les
étudiants voient dans leur pratique (TP) qu'en fait, ça leur
simplifie la vie (ce qui est vrai), il faut expliquer la différence
de contexte.
Un étudiant a souvent du mal à réaliser que ce qu'il prend
pour un gros projet (5000 LOC, 240h de travail) ne représente
pas grand chose au niveau industriel, et que les règles qu'on
présente sont là pour gérer des problèmes qui ne se posent
pas sur d'aussi petit projets.
Marc Boyer
Michael DOUBEZ a écrit :Marc Espie wrote:In article ,
Marc Boyer wrote:Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Une bonne partie de l'informatique, c'est cense etre faire des choses
qui marchent de facon previsible.
99% de ce qu'on fait est debile, c'est le 1% restant qui presente
de l'interet.
Il faut s'arranger pour que les 99% soient les plus simples possibles,
de facon mecanique, ce qui veut dire prendre des automatismes corrects.
(comme presenter son code toujours de la meme facon, verifier les appels
systemes qui peuvent echouer, ne pas laisser passer de warnings a la
compilation).
Si tu autorises les gens a prendre des habitudes differentes "parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Un TP est un temps limité. Je comprends qu'il soit souhaitable de se
concentrer sur les objectifs du TP plutôt que de passer du temps sur
l'aspect qualité (qui est une mesure assez vague). En plus, le message
est plus clair si il n'est pas parasité par des considérations
secondes par rapport à ce qui doit être démontré.
L'aspect qualité est en aucune manière une mesure "assez vague". Il
existe des facteurs et des critères qualité définis depuis au moins 1977
(approche de Mac Call, à l'époque chez General Electric) et des
métriques qui permettent de les mesurer. des outils logiciels comme
Logiscope de Telelogic mettent en oeuvre cette démarche et j'utilise cet
outil pour les audits de code.
C'est là qu'on s'aperçoit, dans
l'industrie, les ravages que peut faire une approche pédagogique qui ne
prend pas en compte les aspects qualité lors de l'écriture de code...
Par ailleurs, ce n'est pas pour rien qu'il existe tant de manuels de
règles de programmation dans les projets industriels et ce, quel que
soit le langage utilisé.
Je ne vois pas l'interet de s'encombrer la tete avec plusieurs facons
de faire du code. On s'en prend une qui est correcte et on s'y tient.
Tout à fait d'accord
Les aficionados de PERL vont faire une attaque. :)
Ben oui mais Perl encourage-t-il une approche qualité ?
Je te laisse le soin de répondre à cette question.
Michael DOUBEZ a écrit :
Marc Espie wrote:
In article <slrngodgcn.396.Marc.Boyer@gavarnie.cert.fr>,
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> wrote:
Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Une bonne partie de l'informatique, c'est cense etre faire des choses
qui marchent de facon previsible.
99% de ce qu'on fait est debile, c'est le 1% restant qui presente
de l'interet.
Il faut s'arranger pour que les 99% soient les plus simples possibles,
de facon mecanique, ce qui veut dire prendre des automatismes corrects.
(comme presenter son code toujours de la meme facon, verifier les appels
systemes qui peuvent echouer, ne pas laisser passer de warnings a la
compilation).
Si tu autorises les gens a prendre des habitudes differentes "parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Un TP est un temps limité. Je comprends qu'il soit souhaitable de se
concentrer sur les objectifs du TP plutôt que de passer du temps sur
l'aspect qualité (qui est une mesure assez vague). En plus, le message
est plus clair si il n'est pas parasité par des considérations
secondes par rapport à ce qui doit être démontré.
L'aspect qualité est en aucune manière une mesure "assez vague". Il
existe des facteurs et des critères qualité définis depuis au moins 1977
(approche de Mac Call, à l'époque chez General Electric) et des
métriques qui permettent de les mesurer. des outils logiciels comme
Logiscope de Telelogic mettent en oeuvre cette démarche et j'utilise cet
outil pour les audits de code.
C'est là qu'on s'aperçoit, dans
l'industrie, les ravages que peut faire une approche pédagogique qui ne
prend pas en compte les aspects qualité lors de l'écriture de code...
Par ailleurs, ce n'est pas pour rien qu'il existe tant de manuels de
règles de programmation dans les projets industriels et ce, quel que
soit le langage utilisé.
Je ne vois pas l'interet de s'encombrer la tete avec plusieurs facons
de faire du code. On s'en prend une qui est correcte et on s'y tient.
Tout à fait d'accord
Les aficionados de PERL vont faire une attaque. :)
Ben oui mais Perl encourage-t-il une approche qualité ?
Je te laisse le soin de répondre à cette question.
Michael DOUBEZ a écrit :Marc Espie wrote:In article ,
Marc Boyer wrote:Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Une bonne partie de l'informatique, c'est cense etre faire des choses
qui marchent de facon previsible.
99% de ce qu'on fait est debile, c'est le 1% restant qui presente
de l'interet.
Il faut s'arranger pour que les 99% soient les plus simples possibles,
de facon mecanique, ce qui veut dire prendre des automatismes corrects.
(comme presenter son code toujours de la meme facon, verifier les appels
systemes qui peuvent echouer, ne pas laisser passer de warnings a la
compilation).
Si tu autorises les gens a prendre des habitudes differentes "parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Un TP est un temps limité. Je comprends qu'il soit souhaitable de se
concentrer sur les objectifs du TP plutôt que de passer du temps sur
l'aspect qualité (qui est une mesure assez vague). En plus, le message
est plus clair si il n'est pas parasité par des considérations
secondes par rapport à ce qui doit être démontré.
L'aspect qualité est en aucune manière une mesure "assez vague". Il
existe des facteurs et des critères qualité définis depuis au moins 1977
(approche de Mac Call, à l'époque chez General Electric) et des
métriques qui permettent de les mesurer. des outils logiciels comme
Logiscope de Telelogic mettent en oeuvre cette démarche et j'utilise cet
outil pour les audits de code.
C'est là qu'on s'aperçoit, dans
l'industrie, les ravages que peut faire une approche pédagogique qui ne
prend pas en compte les aspects qualité lors de l'écriture de code...
Par ailleurs, ce n'est pas pour rien qu'il existe tant de manuels de
règles de programmation dans les projets industriels et ce, quel que
soit le langage utilisé.
Je ne vois pas l'interet de s'encombrer la tete avec plusieurs facons
de faire du code. On s'en prend une qui est correcte et on s'y tient.
Tout à fait d'accord
Les aficionados de PERL vont faire une attaque. :)
Ben oui mais Perl encourage-t-il une approche qualité ?
Je te laisse le soin de répondre à cette question.
Marc Boyer a écrit :On 2009-02-02, Marc Espie wrote:In article ,
Marc Boyer wrote:Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Je pense que tu as mal compris mon propos.Si tu autorises les gens a prendre des habitudes differentes "parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Je n'autorise pas ce genre de chose. Simplement, quand tu énonces
une règles "genre, les variables partagées, c'est mal", et que les
étudiants voient dans leur pratique (TP) qu'en fait, ça leur
simplifie la vie (ce qui est vrai), il faut expliquer la différence
de contexte.
Un étudiant a souvent du mal à réaliser que ce qu'il prend
pour un gros projet (5000 LOC, 240h de travail) ne représente
pas grand chose au niveau industriel, et que les règles qu'on
présente sont là pour gérer des problèmes qui ne se posent
pas sur d'aussi petit projets.
Marc Boyer
C'est toute la difficulté de l'apprentissage de la programmation.
Pour la raison que tu énonces à la fin, il est nécessaire de leur
apprendre à BIEN programmer dès le début même si ça "les embête" (et
le prof avec...). C'est pour le bien de leur carrière de futur
développeur !
Marc Boyer a écrit :
On 2009-02-02, Marc Espie <espie@lain.home> wrote:
In article <slrngodgcn.396.Marc.Boyer@gavarnie.cert.fr>,
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> wrote:
Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Je pense que tu as mal compris mon propos.
Si tu autorises les gens a prendre des habitudes differentes "parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Je n'autorise pas ce genre de chose. Simplement, quand tu énonces
une règles "genre, les variables partagées, c'est mal", et que les
étudiants voient dans leur pratique (TP) qu'en fait, ça leur
simplifie la vie (ce qui est vrai), il faut expliquer la différence
de contexte.
Un étudiant a souvent du mal à réaliser que ce qu'il prend
pour un gros projet (5000 LOC, 240h de travail) ne représente
pas grand chose au niveau industriel, et que les règles qu'on
présente sont là pour gérer des problèmes qui ne se posent
pas sur d'aussi petit projets.
Marc Boyer
C'est toute la difficulté de l'apprentissage de la programmation.
Pour la raison que tu énonces à la fin, il est nécessaire de leur
apprendre à BIEN programmer dès le début même si ça "les embête" (et
le prof avec...). C'est pour le bien de leur carrière de futur
développeur !
Marc Boyer a écrit :On 2009-02-02, Marc Espie wrote:In article ,
Marc Boyer wrote:Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Je pense que tu as mal compris mon propos.Si tu autorises les gens a prendre des habitudes differentes "parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Je n'autorise pas ce genre de chose. Simplement, quand tu énonces
une règles "genre, les variables partagées, c'est mal", et que les
étudiants voient dans leur pratique (TP) qu'en fait, ça leur
simplifie la vie (ce qui est vrai), il faut expliquer la différence
de contexte.
Un étudiant a souvent du mal à réaliser que ce qu'il prend
pour un gros projet (5000 LOC, 240h de travail) ne représente
pas grand chose au niveau industriel, et que les règles qu'on
présente sont là pour gérer des problèmes qui ne se posent
pas sur d'aussi petit projets.
Marc Boyer
C'est toute la difficulté de l'apprentissage de la programmation.
Pour la raison que tu énonces à la fin, il est nécessaire de leur
apprendre à BIEN programmer dès le début même si ça "les embête" (et
le prof avec...). C'est pour le bien de leur carrière de futur
développeur !
Wykaaa writes:Marc Boyer a écrit :On 2009-02-02, Marc Espie wrote:In article ,
Marc Boyer wrote:Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Je pense que tu as mal compris mon propos.Si tu autorises les gens a prendre des habitudes differentes "parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Je n'autorise pas ce genre de chose. Simplement, quand tu énonces
une règles "genre, les variables partagées, c'est mal", et que les
étudiants voient dans leur pratique (TP) qu'en fait, ça leur
simplifie la vie (ce qui est vrai), il faut expliquer la différence
de contexte.
Un étudiant a souvent du mal à réaliser que ce qu'il prend
pour un gros projet (5000 LOC, 240h de travail) ne représente
pas grand chose au niveau industriel, et que les règles qu'on
présente sont là pour gérer des problèmes qui ne se posent
pas sur d'aussi petit projets.
Marc Boyer
C'est toute la difficulté de l'apprentissage de la programmation.
Pour la raison que tu énonces à la fin, il est nécessaire de leur
apprendre à BIEN programmer dès le début même si ça "les embête" (et
le prof avec...). C'est pour le bien de leur carrière de futur
développeur !
C'est idiot. C'est avec des principes comme ça qu'on arrive avec des
générations entières ne sachant ni lire ni écrire en sixième. Quand
on écrit "b, a, b, a, ba, baba", ce n'est du français correct ni
syntaxiquement, ni gramaticalement, ni sémantiquement. Et pourtant,
si on ne le fait pas, on ne saura jamais lire et écrire en français.
De même quand on fait des gammes au piano, ça n'a rien d'une oeuvre
magistrale. Et pourtant il faut le faire pour ensuite être capable de
jouer Chopin.
Alors en TP de programmation, je m'attends à ce qu'on apprenne et
qu'on fasse des exercices de programmations avec des bouts de code qui
seraient totalement déplacés dans un projet professionnel, mais qui
enseigne un point important pour devenir un programmeur professionnel
au bout de quelques années.
Wykaaa <wykaaa@yahoo.fr> writes:
Marc Boyer a écrit :
On 2009-02-02, Marc Espie <espie@lain.home> wrote:
In article <slrngodgcn.396.Marc.Boyer@gavarnie.cert.fr>,
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> wrote:
Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Je pense que tu as mal compris mon propos.
Si tu autorises les gens a prendre des habitudes differentes "parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Je n'autorise pas ce genre de chose. Simplement, quand tu énonces
une règles "genre, les variables partagées, c'est mal", et que les
étudiants voient dans leur pratique (TP) qu'en fait, ça leur
simplifie la vie (ce qui est vrai), il faut expliquer la différence
de contexte.
Un étudiant a souvent du mal à réaliser que ce qu'il prend
pour un gros projet (5000 LOC, 240h de travail) ne représente
pas grand chose au niveau industriel, et que les règles qu'on
présente sont là pour gérer des problèmes qui ne se posent
pas sur d'aussi petit projets.
Marc Boyer
C'est toute la difficulté de l'apprentissage de la programmation.
Pour la raison que tu énonces à la fin, il est nécessaire de leur
apprendre à BIEN programmer dès le début même si ça "les embête" (et
le prof avec...). C'est pour le bien de leur carrière de futur
développeur !
C'est idiot. C'est avec des principes comme ça qu'on arrive avec des
générations entières ne sachant ni lire ni écrire en sixième. Quand
on écrit "b, a, b, a, ba, baba", ce n'est du français correct ni
syntaxiquement, ni gramaticalement, ni sémantiquement. Et pourtant,
si on ne le fait pas, on ne saura jamais lire et écrire en français.
De même quand on fait des gammes au piano, ça n'a rien d'une oeuvre
magistrale. Et pourtant il faut le faire pour ensuite être capable de
jouer Chopin.
Alors en TP de programmation, je m'attends à ce qu'on apprenne et
qu'on fasse des exercices de programmations avec des bouts de code qui
seraient totalement déplacés dans un projet professionnel, mais qui
enseigne un point important pour devenir un programmeur professionnel
au bout de quelques années.
Wykaaa writes:Marc Boyer a écrit :On 2009-02-02, Marc Espie wrote:In article ,
Marc Boyer wrote:Ce qui suppose de savoir comment va se dérouler
la suite de la vie de ce code, ce qui est raisonnable
si on sait qu'on va jeter le code à la fin du TP,
un peu moins si on envisage que ce code soit utilisé
pour de vrai, maintenu, ré-utilisé, adapté...
Euh, mauvaise logique, changer de logique.
Je pense que tu as mal compris mon propos.Si tu autorises les gens a prendre des habitudes differentes "parce que
c'est juste un TP", tu les formes a faire du code qui marchera mal.
Je n'autorise pas ce genre de chose. Simplement, quand tu énonces
une règles "genre, les variables partagées, c'est mal", et que les
étudiants voient dans leur pratique (TP) qu'en fait, ça leur
simplifie la vie (ce qui est vrai), il faut expliquer la différence
de contexte.
Un étudiant a souvent du mal à réaliser que ce qu'il prend
pour un gros projet (5000 LOC, 240h de travail) ne représente
pas grand chose au niveau industriel, et que les règles qu'on
présente sont là pour gérer des problèmes qui ne se posent
pas sur d'aussi petit projets.
Marc Boyer
C'est toute la difficulté de l'apprentissage de la programmation.
Pour la raison que tu énonces à la fin, il est nécessaire de leur
apprendre à BIEN programmer dès le début même si ça "les embête" (et
le prof avec...). C'est pour le bien de leur carrière de futur
développeur !
C'est idiot. C'est avec des principes comme ça qu'on arrive avec des
générations entières ne sachant ni lire ni écrire en sixième. Quand
on écrit "b, a, b, a, ba, baba", ce n'est du français correct ni
syntaxiquement, ni gramaticalement, ni sémantiquement. Et pourtant,
si on ne le fait pas, on ne saura jamais lire et écrire en français.
De même quand on fait des gammes au piano, ça n'a rien d'une oeuvre
magistrale. Et pourtant il faut le faire pour ensuite être capable de
jouer Chopin.
Alors en TP de programmation, je m'attends à ce qu'on apprenne et
qu'on fasse des exercices de programmations avec des bouts de code qui
seraient totalement déplacés dans un projet professionnel, mais qui
enseigne un point important pour devenir un programmeur professionnel
au bout de quelques années.
C'est idiot. C'est avec des principes comme ça qu'on arrive avec des
générations entières ne sachant ni lire ni écrire en sixième. Quand
on écrit "b, a, b, a, ba, baba", ce n'est du français correct ni
syntaxiquement, ni gramaticalement, ni sémantiquement. Et pourtant,
si on ne le fait pas, on ne saura jamais lire et écrire en français.
De même quand on fait des gammes au piano, ça n'a rien d'une oeuvre
magistrale. Et pourtant il faut le faire pour ensuite être capable de
jouer Chopin.
Alors en TP de programmation, je m'attends à ce qu'on apprenne et
qu'on fasse des exercices de programmations avec des bouts de code qui
seraient totalement déplacés dans un projet professionnel, mais qui
enseigne un point important pour devenir un programmeur professionnel
au bout de quelques années.
C'est idiot. C'est avec des principes comme ça qu'on arrive avec des
générations entières ne sachant ni lire ni écrire en sixième. Quand
on écrit "b, a, b, a, ba, baba", ce n'est du français correct ni
syntaxiquement, ni gramaticalement, ni sémantiquement. Et pourtant,
si on ne le fait pas, on ne saura jamais lire et écrire en français.
De même quand on fait des gammes au piano, ça n'a rien d'une oeuvre
magistrale. Et pourtant il faut le faire pour ensuite être capable de
jouer Chopin.
Alors en TP de programmation, je m'attends à ce qu'on apprenne et
qu'on fasse des exercices de programmations avec des bouts de code qui
seraient totalement déplacés dans un projet professionnel, mais qui
enseigne un point important pour devenir un programmeur professionnel
au bout de quelques années.
C'est idiot. C'est avec des principes comme ça qu'on arrive avec des
générations entières ne sachant ni lire ni écrire en sixième. Quand
on écrit "b, a, b, a, ba, baba", ce n'est du français correct ni
syntaxiquement, ni gramaticalement, ni sémantiquement. Et pourtant,
si on ne le fait pas, on ne saura jamais lire et écrire en français.
De même quand on fait des gammes au piano, ça n'a rien d'une oeuvre
magistrale. Et pourtant il faut le faire pour ensuite être capable de
jouer Chopin.
Alors en TP de programmation, je m'attends à ce qu'on apprenne et
qu'on fasse des exercices de programmations avec des bouts de code qui
seraient totalement déplacés dans un projet professionnel, mais qui
enseigne un point important pour devenir un programmeur professionnel
au bout de quelques années.