Discussion :

[vermine]

Le but des pages collaboratives est que les membres puissent faire une grande partie du travail.

Grâce à vos accès aux forums de la rédaction, vous pouvez faire la démarche de relecture orthographique vous-même. Attention que si ce n'est pas milkoseck ou fleb, il faudra que je donne les droits aux relecteurs (prévenez-moi dans ce cas-là).

Donc respectez la même mise en forme que les exercices déjà publiés, faites-les relire, et puis vous pouvez-vous même créer une discussion sur le forum JavaScript (général). Ensuite, je prends le relais : je déplace la discussion avec une redirection permanente et j'annonce l'exercice.

[Gnuum]

Désolé, je n'ai pas fait grand chose dernièrement mais c'est parce que j'ai été très pris! Ca devrait aller un peu mieux à partir du WE prochain.

On va pouvoir tester tout ça avec l'exercice 1.2.4. J'essaierai d'enchaîner le 1.2.5. histoire qu'on boucle cette partie une bonne fois pour toute et qu'on commence à passer à des choses plus intéressantes!

[autran]

Est-ce que vous voulez que je mette un petit exercice rapide sur mon blog pour faire patienter Touit et Beginner pour ce WE de la pentecôte?

[ABCIWEB]

Salut Marc,

Je sais pas ce que les autres en pensent mais j'ai envie de dire que tu fais bien ce que tu veux sur ton blog. Quand bien même tu mettrais un exercice qui n'est pas encore validé je ne vois pas où est le problème. Surtout que le prochain non encore validé a été lu et relus, donc c'est plus une histoire de principe que de contenu.

Faudrait d'ailleurs à mon avis revoir le principe de validation car si Thomas est le seul à pouvoir le faire cela fait une grosse charge de travail. Je pense qu'à partir du moment où des personnes compétentes (ex : SylvainPV, NoSmoking, danielhagnoul pour citer ceux qui ont participé à cette discussion) ont déjà relus et approuvés un exercice après nous, tu devrais pouvoir être en mesure de le proposer pour une dernière relecture et validation. Ainsi Thomas pourrait n'intervenir que quand il le souhaite/peut et mieux se réserver pour les parties plus essentielles.

Et puis même une fois publiés les exercices sont modifiables, donc rien n'empêche de rajouter quelques précisions si besoin par la suite. A mon avis mieux vaut avancer que de viser la perfection "absolue" pour chaque publication.

[vermine]

En fait, le seul droit supplémentaire de Thomas et Sylvain est de créer des sections. Pour le reste, il me semble que vous avez tous les droits nécessaires.

Pour la rédaction, vous pouvez tous créer et modifier un exercice.

Pour la relecture orthographique, vous avez tous l'accès aux forums de la rédaction et plus particulièrement au forum des relectures.

Pour la publication, il y a le fait de rendre visible l'exercice. Ça, je ne sais pas qui à ce droit à part moi.

Le seul souci est de devoir ajouter manuellement les relecteurs orthographiques. Je pense que seul moi peut le faire. Nous en avons déjà deux.

Pour l'annonce, vous pouvez tous créer une discussion sur le forum JavaScript qui sera déplacée par un modérateur sur le forum Exercices avec une redirection permanente.

Donc normalement, une fois que vous avez le feu vert du relecteur technique, vous pouvez lancer les démarches.

[SylvainPV]

J'ai mis à jour le premier post avec l'état des exercices. Si vous voulez que je mette à jour ou si j'ai oublié des trucs, pensez à me MP ou à poster le plan mis à jour à la suite de ce topic.

Je reviens sur quelques exercices:

1.2.3 je suis toujours ennuyé par cet exercice, qui met en avant le switch case fall-through qui est considéré par beaucoup comme une mauvaise pratique en raison de sa cause fréquente de bugs. C'est d'ailleurs remonté comme un problème dans la configuration par défaut de ESLint : http://eslint.org/docs/rules/no-fallthrough ; donc perso je ne suis pas favorable pour en faire un exercice, mais je vous laisse en discuter entre vous.

1.3.1 les boucles for sont un excellent moyen d'introduire let et const d'ES6, qui remplacent complètement var (sauf pour ceux qui veulent volontairement du hoisting, mais là encore c'est souvent considéré comme une mauvaise pratique). Donc si on reste dans l'idée de faire du ES6 de préférence, surtout depuis que Node.js en a un excellent support natif, je pense qu'il vaut mieux utiliser const pour les références d'objets et let pour les références primitives.
Il faudrait aussi parler des boucles for..in et for..of dans cet exercice (ou un second exercice sur les boucles for)

1.3.2 #Number.toFixed(2) me semble plus pratique que le calcul Math.round(#Number*100)/100, et rend plus explicite le cast en String.

1.33 cette méthode de dédoublonnage présente de nombreux inconvénients : on perd l'ordre initial et cela ne marche que pour des valeurs primitives. Une méthode très simple pour dédoublonner est d'utiliser indexOf:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
Array.prototype.removeDuplicates = function(){     var deduplicatedArray = [];
    for(var i=0, l=this.length; i<l ; i++){
        if(this.indexOf(this[i]) === i){
            deduplicatedArray.push(this[i])
        }
    }
    return deduplicatedArray
}

Cela marche pour tout type d'élément et préserve l'ordre initial.

En ES6, l'idéal est de passer par un Set:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Array.prototype.removeDuplicates = function(){     return [...new Set(this)]
}

Si l'objectif de cet exercice est d'apprendre les mécanismes de tri des tableaux, il faudrait l'expliciter dans le titre de l'exercice et trouver un autre exemple qui implique de créer sa propre fonction de tri. Par exemple faire une fonction qui trie un tableau selon une certaine colonne et un ordre de tri.

[autran]

Salut Sylvain,
Merci pour cette relecture, je réponds pour les exos qui me concernent*:

• 1.3.1Si le rédacteur en titre pour le cours (Thomas) met une couche sur let et const alors OK pour moi. Pour for .. in et for .. of, je préférerais faire un exercice à part et garder celui-là avec le for classique pour rester dans un esprit d'enseignement universel de l'algorithmique qui ciblerait tous les langages (JAVA C ….)
• 1.3.3Sylvain aie aie aie, je n'ai pas de connaissance de ce concept de prototype. Je suis démasqué un développeur d'opérette tout juste bon a être chef de projet. On condamne cet exercice à n'épurer que des valeurs primitives

[ABCIWEB]

1.2.3 je suis toujours ennuyé par cet exercice, qui met en avant le switch case fall-through qui est considéré par beaucoup comme une mauvaise pratique en raison de sa cause fréquente de bugs. C'est d'ailleurs remonté comme un problème dans la configuration par défaut de ESLint : http://eslint.org/docs/rules/no-fallthrough ; donc perso je ne suis pas favorable pour en faire un exercice, mais je vous laisse en discuter entre vous.

Les raisons pour en faire un exercice :
Il est déjà fait et en ligne.
C'est la suite logique de l'étude du switch sans "case fall-through", il vient donc à point nommé.
La doc mozilla explique le "case fall-through" sur plusieurs paragraphes donc c'est assez logique d'en faire un exercice.
Il est le support à la présentation d'autres fonctions/méthodes.
Les plus fréquentes causes d'erreurs viennent d'étourderies quand on oublie de mettre un "break" alors que l'on sait qu'il en faut un. Je vois pas en quoi le fait de déconseiller le "falls through" arrangerait cela. Au contraire, étudier ce cas particulier permet de mieux comprendre et se sensibiliser au problème.
Enfin dans tous les cas il est impossible de coder sans faire attention à ce que l'on fait. Alors pourquoi déconseiller plus particulièrement le "fall-through" dans un switch ? Doit-on en faire autant pour toutes les fonctions/méthodes qui se comportent différemment suivant que l'on fourni ou non un second argument optionnel ?

Ce que je retiens de la lecture de ton article est le bon conseil de toujours indiquer un commentaire quand on fait un "fall-through" intentionnel. Cela me paraît plus "raisonnable" et facile à intégrer dans l'exercice sans pour autant tout mettre en l'air pour des raisons discutables.

1.3.2 #Number.toFixed(2) me semble plus pratique que le calcul Math.round(#Number*100)/100, et rend plus explicite le cast en String.

Ok, je remplacerai Math.round (EDIT : c'est fait)

1.3.3 cette méthode de dédoublonnage présente de nombreux inconvénients : on perd l'ordre initial et cela ne marche que pour des valeurs primitives.

On peut mettre cet exercice en "facultatif". J'avais déjà mis un commentaire pour dire que c'était une ancienne méthode, on peut préciser qu'il vaut mieux ne pas l'utiliser et dire que l'intérêt est seulement dans l'originalité de cet algorithme "vintage" ?

Une méthode très simple pour dédoublonner est d'utiliser indexOf:

[code]Array.prototype.removeDuplicates = function(){ var deduplicatedArray = [];
for(var i=0, l=this.length; i<l ; i++){
if(this.indexOf(this[i]) === i){
deduplicatedArray.push(this[i])
}
}
return deduplicatedArray
}

Normalement on essaies de faire des exercices avec des difficultés progressives. A ce niveau de la progression du tuto je doute que cette méthode soit perçue comme très simple. L'exercice 1.3.4 qui utilise également indexOf me paraît plus abordable.
Cette solution pourrait être donnée en dernière solution de dédoublonnage la plus avancée mais avec les explications nécessaires qui vont avec.

Pour le reste je ne pense pas que nous ayons eu à l'esprit (en tous cas pas moi) de faire ces exercices dans l'optique de présenter des fonctions de tris sur les tableaux. C'est plus dans l'optique de présenter/manipuler les tableaux en utilisant des fonctions/méthodes de base. Mais en effet pourquoi pas d'autres exercices spécifiques sur le sujet...

[SylvainPV]

Oublier le break dans un switch case est reconnu comme une erreur très courante, chez les débutants mais même encore chez les habitués. Quand je vois un fall-through dans un code, il s'agit d'un bug 9 fois sur 10. C'est aussi une structure très fragile car elle repose sur l'ordre des déclarations case. Sans un regard attentif, il est facile de casser un fonctionnement existant basé sur un fall-through en supprimant une déclaration précédente ou en en changeant l'ordre. Même si tu sais parfaitement comment utiliser intelligemment un fall-through, il faut imaginer que toi ou quelqu'un d'autre repasse sur ce code dans 6 mois, et n'aura plus du tout ça à l'esprit. Mettre systématiquement un commentaire explicite est une bonne idée, mais le mieux selon moi est de réécrire le code de manière à se débarrasser du fall-through, ce qui est toujours possible.

Idéalement, ça serait bien que tous nos codes postés valident les recommandations ESLint. Je ne dis pas que c'est la sacro-sainte bible, il y a toujours des règles et des cas particuliers pour lesquels on peut débattre et chipoter. Mais ça reste quand même l'outil de qualité de code n°1 pour ES6.

Pour les exos 1.3.3 et 1.3.4, il est écrit Objectif: Tri sur les tableaux ??? Il faudrait clarifier le rôle de ces exercices.

[ABCIWEB]

Oublier le break dans un switch case est reconnu comme une erreur très courante, chez les débutants mais même encore chez les habitués. Quand je vois un fall-through dans un code, il s'agit d'un bug 9 fois sur 10. C'est aussi une structure très fragile car elle repose sur l'ordre des déclarations case. Sans un regard attentif, il est facile de casser un fonctionnement existant basé sur un fall-through en supprimant une déclaration précédente ou en en changeant l'ordre. Même si tu sais parfaitement comment utiliser intelligemment un fall-through, il faut imaginer que toi ou quelqu'un d'autre repasse sur ce code dans 6 mois, et n'aura plus du tout ça à l'esprit. Mettre systématiquement un commentaire explicite est une bonne idée...

Encore une fois ce que tu dis ici pourrait s'appliquer à peu près pour n'importe quelle structure de code avec ou sans switch. Une structure if/else doit également respecter un ordre et fonctionnera aussi moins bien en supprimant une condition etc. Ce n'est pas un principe spécifique au switch donc pas un argument convainquant. Ce sont évidemment les commentaires qui font la différence pour la maintenance d'un code, avant, pendant et sans doute aussi après ESLint. Rien de nouveau ici. Et j'aimerais bien aussi qu'on m'explique en quoi le fait de ne pas utiliser de "fall-through" permettrait de ne pas oublier un break quand il est nécessaire. Franchement c'est très subjectif, concentrons-nous sur l'essentiel.

idéalement, ça serait bien que tous nos codes postés valident les recommandations ESLint. Je ne dis pas que c'est la sacro-sainte bible, il y a toujours des règles et des cas particuliers pour lesquels on peut débattre et chipoter. Mais ça reste quand même l'outil de qualité de code n°1 pour ES6.

Si tu oublies le titre extrémiste, tout le contenu de l'article que tu cites insiste plus particulièrement sur les commentaires. On respecte donc bien l'esprit en mettant un commentaire.

Doit-on allez plus loin, mettre un voile noir et cacher cette utilisation proscrite par la nouvelle religion ? Devoir allez chez les athées pour connaître toutes les possibilités de cette fonction ? Dire aussi à mozilla de supprimer ses exemples de code fallacieux ? Faire une lettre ouverte à tous langages de programmation qui utilisent un swicth avec fall-through pour leur dire que si on ne fait pas attention ça ne marche pas comme prévu (grande nouvelle ).

Faut savoir faire le tri dans les recommandations et les appliquer en fonction du contexte. J'en ai lu des bien plus pertinentes et si on peut critiquer celle-ci - dans sa version extrémiste - avec autant de facilité c'est qu'elle n'est pas essentielle. Alors pourquoi en faire tout un fromage ? Ce serait faire preuve d'intégrisme mal placé dans notre contexte puisque justement on explique l'utilisation du switch avec et sans break !

[SylvainPV]

Pour moi c'est le même problème que pour l'insertion automatique de points-virgule, on peut les omettre quand on connaît le mécanisme et ses limites. Mais on conseille le plus souvent aux débutants de toujours mettre un point virgule à la fin d'une ligne au cas où ils tombent sur des cas particuliers pour lesquels l'ASI est omise. Malgré cela il y a des gens qui refusent catégoriquement de mettre des points-virgule, même si c'est virtuellement gratuit. Perso je trouve que c'est un élitisme inutile et dangereux. C'est pareil pour les switch, je préfère dire aux débutants de toujours mettre un break dans chaque case, plutôt que d'expliquer que ça peut avoir un faible intérêt si on sait ce qu'on fait. Ce n'est pas de la religion, c'est un raisonnement beaucoup plus pragmatique après toutes les erreurs de break oublié que j'ai vu en dix ans de JS.

Enfin, je suis ok si l'exo est indiqué facultatif et si on insiste pour ajouter un commentaire //fall through

[ABCIWEB]

On peut trouver rapidement un terrain d'entente sur le point virgule, cela ne fait pas débat bien longtemps tellement les avantages sont évidents. Mais je ne vois toujours pas le rapport avec un break derrière un swicth et encore moins avec une position élitiste ou dangereuse.

Comme "tout le monde" j'utilise à plus de 90% la structure swicth avec un break à la fin de chaque case mais il m'arrive parfois de l'oublier. Tout comme il m'arrive parfois d'oublier un point virgule à la fin d'une ligne, ou un exit à la fin d'un header location en php alors que je sais pertinemment qu'il en faut un. Le caractère obligatoire ou pas n'a rien à voir avec ces erreurs d'inattention et ce n'est pas en amputant une des fonctionnalités du switch que tu y changeras quelque chose.

Dire d'un raisonnement qu'il est pragmatique quand il peut produire des résultats qui restent aléatoires (ne garanti en rien l'absence de fautes d'inattention qui sont les plus fréquentes) tout en étant par ailleurs castrateur, est un peu rapide, et a plus de relents religieux que purement logiques. Si cela peut parfois éviter une erreur de ci de là, c'est une goutte d'eau comparé au erreurs d'étourderies et même handicapant quand les structures correspondantes if/else sont moins lisibles. Le bilan est très critiquable, et l'intérêt très marginal. Il y a plus de 10 ans moi aussi que je fréquente les forums de programmation web et c'est la première fois que je lis ça à propos du swicth. Si cela était si important, on en aurait entendu parlé bien avant les nouvelles révélations divines de ESLint. Après je ne dis pas qu'il ne faut pas évoluer, mais il faut des arguments un peu plus motivants/solides/utiles/efficaces.

Cela dit je comprends bien l'intérêt de ta remarque. Ok pour le //fall through. Par contre je ne changerai pas moi-même cet exercice en facultatif car je ne suis pas d'accord : on se doit d'expliquer entièrement le fonctionnement de cette instruction de base, et les apprenants doivent le connaître. Libre à eux de suivre ensuite les recommandations de tel ou tel gourou/système particulier. Et puis d'autres méthodes et fonctions sont présentées à l'occasion, ce serait donc totalement contre productif.

Il y a certainement de meilleures croisades à entreprendre, notamment en se concentrant sur les exercices à venir plutôt que sur les exercices passés, terminés et publiés. Bah sinon on ne va pas dans le bon sens et on n'est pas rendu !


EDIT c'est fait pour le //fall through

[SylvainPV]

Interdire l'absence de break dans un case permet de configurer les linters et les IDE pour signaler ces cas en tant qu'erreurs, et ainsi mettre fin aux fautes d'inattention.

Mais bon, je pense qu'on arrivera pas à se mettre d'accord, ma foi tant pis, j'aurais exposé mon point de vue. Je laisse les autres exposer le leur sur le caractère facultatif de cet exercice.

[autran]

Sylvain, Alain, et les autres,

Sur le fond je ne peux pas arbitrer votre débat compte tenu de mon approche de développeur full bug et zéro qualité.

Sur la forme et le modus-operandi de la publication des articles je veux bien m’y risquer. Je pense que notre initiative, qui au départ s’appelait apprendre Node.js from scratch, ne produit pas assez.

Je remarque que certains exercices sont depuis un moment validés autour d’un consensus mou. Néanmoins ils ne sont pas publiés car on cherche à avoir une validation totale. J’ai peur que les délais de publication ne rebutent les apprenants et donc compromettent le projet.

Ce que je propose, pour aller plus vite serait de soumettre à la publication (or déplacement par Vermine vers la page d’accueil) dès que plusieurs contributeurs sont d’accord sur un article.
Par exemple, pour l’exercice qui fait débat entre Sylvain et Alain, je suis d’avis qu’il soit soumis à une correction orthographique et qu’on le passe à l’issue en visible et qu’on le suive en tutorat sur un fil.
Comme ça on fait bosser nos apprenants et vivre le cahier d’exercices.
Sur le fil, rien n’empêche Sylvain d’avertir sur le danger de certaines pratiques d’écriture du code pour lesquelles cet exercice pourrait avoir valeur de cas d’école.

[vermine]

Effectivement, et les exercices peuvent toujours être édités par la suite. On ajouterait alors une réponse à la discussion pour avertir de ces changements.
Notez également que cet avertissement peut être ajouté dans la solution de l'exercice.

[ABCIWEB]

Interdire l'absence de break dans un case permet de configurer les linters et les IDE pour signaler ces cas en tant qu'erreurs, et ainsi mettre fin aux fautes d'inattention.

Mais bon, je pense qu'on arrivera pas à se mettre d'accord, ma foi tant pis, j'aurais exposé mon point de vue. Je laisse les autres exposer le leur sur le caractère facultatif de cet exercice.

Le premier point est ouvert : si personnellement je n'utiliserais pas cette option car j'y trouve plus d'inconvénients que d'avantages, je peux comprendre sans problème que le bilan soit plus favorable pour d'autres et je ne dis pas que ce n'est pas pertinent dans certains contextes.

Cela dit, même si je regarde en dehors de mon expérience personnelle, le switch étant très utilisé et documenté dans les deux principaux langages de programmation web (javascript et php), si le besoin de traiter le problème du "fall through" était si fondamental, il y aurait plus de doc à ce sujet. Le moins qu'on puisse dire est que la recommandation de ne plus l'utiliser du tout ne fait pas l'unanimité (faut vraiment chercher). Pour exemple cet article a été publié, donc relu et passé dans de nombreuses mains sans objection à ce sujet
Mais bon cela reste un point ouvert tant que cela ne concerne que des options de configurations.

Le second point est pour moi moins discutable car c'est un problème de principe : le swicth est une instruction javascript très utilisée (tout autant en php), et à ce titre on se doit de la traiter complètement dans sa globalité et dans un contexte général. Et non pas dans le contexte plus restreint des configurations/recommandations de tel ou tel IDE. Sinon cela revient à créer des unijambistes sous prétexte que ça leur fera un pied en moins à laver. Laissons-les plutôt choisir en connaissance de cause !

On est vers le tout début du tuto et on fait des exercices pour présenter des fonctions/instructions/méthodes et notre doc de référence est MDN, pas ESLINT. Les conseils de programmation doivent arriver après la connaissance du langage, non pas la précéder. Sinon tu suis le même principe que ces formations php spécifiques à certains frameworks, accessibles aux débutants mais qui au final produisent des gens perdus dès qu'ils mettent le nez par la fenêtre pour regarder autre chose. Est-ce un exemple à suivre ? Par ailleurs si on suit ta logique, on devra bientôt re modifier ou supprimer d'autres exercices en fonctions des recommandations des prochaines versions d'ESLINT ? Adieu l'intérêt général.

Autant je peux comprendre qu'on ajoute des commentaires pour informer dans ton sens, autant je trouve hallucinant qu'on puisse décider de rendre cette seconde partie facultative s'agissant d'une instruction aussi fondamentale que le switch. Si les conseils d'utilisation peuvent compléter une formation, ils ne doivent en aucun cas l'amputer. Qu'est-ce qui te permet de penser que c'est facultatif d'un point de vue global ? L'utilisation dans un contexte particulier ! C'est vraiment très arbitraire.

Pour terminer certes tu as exposé ton point de vue mais jamais tu n'as répondu sur le fond à mes objections. Faut donc pas s'étonner que je rabâche un peu

[SylvainPV]

Bon je ne pensais pas insister mais si tu y tiens, je vais répondre à tes diverses objections

si le besoin de traiter le problème du "fall through" était si fondamental, il y aurait plus de doc à ce sujet

Il y en a pléthore, et ce dans tous les langages concernés. Tu n'as pas dû chercher bien loin. Pour citer la page Wikipédia de l'instruction switch: https://en.wikipedia.org/wiki/Switch...nt#Fallthrough

In practice, fallthrough is usually prevented with a break keyword at the end of the matching body, which exits execution of the switch block, but this can cause bugs due to unintentional fallthrough if the programmer forgets to insert the break statement. This is thus seen by many as a language wart, and warned against in some lint tools.

Et un extrait du livre JavaScript : The Good Parts par Crockford (qui est un des livres les plus célèbres sur la qualité de code JavaScript, rappelons-le)

Someone wrote to me once suggesting that JSLint should give a warning when a case falls through into another case. He pointed out that this is a very common source of errors, and it is a difficult error to see in the code. I answered that that was all true, but that the benefit of compactness obtained by falling through more than compensated for the chance of error.The next day, he reported that there was an error in JSLint. It was misidentifying an error. I investigated, and it turned out that I had a case that was falling through. In that moment, I achieved enlightenment. I no longer use intentional fall throughs. That discipline makes it much easier to find the unintentional fall throughs.

le swicth est une instruction javascript très utilisée (tout autant en php), et à ce titre on se doit de la traiter complètement dans sa globalité et dans un contexte général

Il y a une différence entre le fait de parler du fall-through et le fait de le mettre en application dans un exercice. Un avertissement du style "Attention, n'oubliez pas l'instruction break sinon le code du case suivant sera exécuté" donne la même quantité d'informations, mais l'intention n'est pas du tout la même. En interdisant les fall through, personne n'est "amputé" de quoi que ce soit car une instruction switch peut toujours être facilement réécrite pour se débarrasser d'un fall-through. Si tu penses le contraire, donne-moi un exemple.

notre doc de référence est MDN, pas ESLINT

Cela n'a rien à voir. MDN est une référence documentaire exhaustive, ESLint est un outil de qualité de code. MDN documente de nombreuses fonctions dépréciées ou propriétaires, ce n'est pas pour autant qu'on va se permettre de les utiliser.

Les conseils de programmation doivent arriver après la connaissance du langage, non pas la précéder

Je ne suis pas du tout d'accord sur ce point. Ces deux aspects de l'apprentissage ont toujours cohabité. De tous les développeurs JS existants aujourd'hui, combien peuvent prétendre connaître ne serait-ce que la moitié de la spécification du langage ? Est-ce que tu as appris toutes les règles d'ASI avant de mettre un point virgule à ta première ligne de JS ? Aussi, poser des bonnes pratiques n'a rien à voir avec le fait d'enseigner un framework, ne mélange pas tout.

Par ailleurs si on suit ta logique, on devra bientôt re modifier ou supprimer d'autres exercices en fonctions des recommandations des prochaines versions d'ESLINT ? Adieu l'intérêt général.

Pour les best practices en tout cas, oui bien sûr. On est sur un forum de développeurs professionnels, et la qualité de code doit être un sujet essentiel. Que ce soit ESLint ou un autre linter, ça me paraît normal et nécessaire de passer au linter les codes que l'on poste sur Developpez. Surtout s'il s'agit de former d'autres futurs professionnels, c'est totalement dans l'intérêt général. Même chose pour les parties dépréciées du langage. Ce n'est pas pour rien qu'on est en train de mettre à jour la FAQ JavaScript de Developpez en supprimant/modifiant toutes les vieilles entrées bourrées d'éléments dépréciés.

[Gnuum]

Ne vous battez pas

En fait vous avez tous les 2 raisons et rappelons que notre démarche n'est pas seulement d'apprendre à programmer mais également les bonnes pratiques de programmation.
Personnellement, je ne connaissais pas le débat que nous a présenté Sylvain car j'utilise rarement le switch dans des comportements compliqués pour la simple et bonne raison qu'en général cela démontre la présence d'une notion à abstraire.

Je pense qu'il faut préciser que la non utilisation d'un break est source d'erreur et qu'il est plutôt déconseillé de le faire. Après avoir dit cela, est-ce qu'un exercice sur le sujet est de trop? Ma réponse n'est pas affirmative. D'un côté ça ne semble pas forcément logique d'accorder un exercice ou une partie d'exercice à un comportement déconseillé. D'un autre côté, pour éviter cette erreur et pouvoir éventuellement la déboguer, ne vaut-il pas mieux comprendre le fonctionnement complet du switch? De plus, cela permet de rajouter un exercice pour progresser en douceur et renforcer les notions.

En résumé, ça ne me parait pas une question fondamentale et je pense qu'on peut maintenir l'exercice tout en rajoutant une remarque déconseillant l'utilisation du switch de cette manière. Ce qui rejoint vos 2 opinions au final car je pense que c'est la meilleure manière de maîtriser le switch tout en en évitant les pièges.

EDIT: je viens de m'apercevoir que cela a déjà été fait!

[Gnuum]

Sinon, je vous propose de mettre en prod l'exercice 1.2.4 puisqu'il me semble ok pour tout le monde maintenant.
Tout d'abord, il faut le faire corriger orthographiquement. Qui saurait comment faire ça et expliquer aux autres le processus (désolé mais je suis un peu débutant sur ces aspects)?
Ensuite, je pourrais rendre l'exercice visible (je ne sais pas si quelqu'un d'autre a le droit de le faire) et on pourra mettre un sujet sur le forum JavaScript et demander à Xavier de le déplacer.

[SylvainPV]

Personne ne se bat, au pîre ça relève de la chamaillerie D'autant qu'on s'est déjà mis d'accord sur un compromis pour cet exo : un commentaire dans le code pour indiquer le fall through intentionnel, et un message d'avertissement indiquant que certains considèrent ça comme une mauvaise pratique. On peut passer à la suite.

Pour éviter tout malentendu, Thomas, peux-tu renommer mon rôle de "correcteur" à "relecteur technique" ? Je n'ai pas d'autorité sur le contenu d'un exercice, seulement un rôle de conseil. C'est aux rédacteurs d'exercices de décider quoi faire de mes remarques, et je préfère qu'ils les considèrent comme un complément enrichissant plutôt qu'une contrainte agaçante.