Personne n'a dit qu'assert était une surcharge cognitive. C'est très bien, assert.

Et bien sur qu'il faut faire la difference etc. 

Et qu'il est important d'écrire des programmes qui marchent. Et de les tester avant la mise en production. Pardi. #banalités

D'où la question : est-ce que le débutant qui écrit une classe fraction peut se prémunir contre l'appel du constructeur (dans du code écrit par un "on" indéterminé) avec un paramètre à 0, ou est-ce qu'il ne peut pas ? Doit-il, ne doit il pas, ou doit-il ne pas ? Et comment.

-
Edité par michelbillaud 26 octobre 2018 à 11:20:02

michelbillaud a écrit:

Je te rappelle que nous répondons à un _débutant_ qui fait un _exercice_. C'est pas un responsable d'exploitation qui s'arrache les cheveux pour faire tourner un million de processus sur des bécanes surchargées, et qui fait compiler ses applications avec le maximum d'options d'optimisation pour que ça rentre.

Se pose alors la question du but des exercices que l'on donne à nos débutants:

Veut-on simplement  simplement qu'ils puissent le réussir, en prenant, au besoin, de mauvaises habitudes qu'il devront s'efforcer d'abandonner par la suite (s'ils en prennent) ou veut-on essayer de leur inculquer directement les bonnes habitudes, celles qui leur permettront -- non seulement "à titre professionnel", mais aussi pour la suite des exercices que nous leur donneront -- de s'en sortir "sans trop de difficultés" et de résoudre leurs problèmes "par eux même"?

Sincèrement, je préfère la deuxième solution, vu que cela nous évitera de devoir rectifier le tir par la suite

michelbillaud a écrit:

Les économies de bout de chandelle (on parle bien du coût de la comparaison d'un entier à 0 dans un constructeur...)  dans un programme qui n'est  absolument pas critique ni contraint en temps ou en espace et que personne n'utilisera de toutes façons, c'est des considérations qui ne sont pas prioritaires _pour lui_. Et ce n'était pas sa question.

Des "économies de bout de chandelle", c'est vite dit!!!

Le problème n'est pas forcément la présence ou non d'un test dans le code de production (en release), le problème est de donner l'habitude au débutant de s'assurer que la logique qui mène à une situation potentiellement dangereuse sera suffisamment stricte que pour éviter ces situations, sachant que cette vérification n'a réellement de sens qu'en mode débug.  Et surtout de lui donner les bons outils pour faire ce genre de vérification.

Comme tu le dit, la présence de ce test ne prendra effectivement de l'importance que lorsque le débutant commencera à créer des programmes plus "critiques" (s'il y vient un jour).

Mais, encore une fois, la question est "pourquoi faudrait il faire le travail deux fois?" pourquoi devrions nous lui donner l'habitude de faire ces vérifications en lançant une exception, si c'est pour lui dire, par la suite "ben, en fait, dans ce cas là, une assertion sera plus correcte, car il s'agit de s'assurer que la logique qui nous a amené ici était correcte"?

L'un dans l'autre, les économies ne se font pas au niveau du programme, comme tu semble le croire, mais bien au niveau de l'apprentissage lui-même

-
Edité par koala01 26 octobre 2018 à 12:56:42

Bon, comme on parle des exercices de débutants,

• tu regardes les exercices qui sont donnés dans n'importe quel tutoriel (pour arriver à leur faire écrire une boucle avec un si alors sinon dedans),
• tu nous fais voir la solution qui te parait se conformer à ces fameuses "bonnes habitudes que l'on doit prendre dès le début".

Et après on reparle de l'ordre dans lequel on doit introduire les divers sujets dans la progression pédagogique. Parce qu tu ne vas pas arriver à parler de contrat à quelqu'un qui n'a pas compris ce qu'était une fonction.

Considérations de bout de chandelle : ok, tu écrit un programme quelconque qui fait des trucs significatifs  sur des fractions, et tu mesures le temps d'exécution des trois versions (avec if(), avec assert, et sans). Et après on regarde quelle décimale du pourcentage ça touche.

-
Edité par michelbillaud 26 octobre 2018 à 16:25:47