Lorsque vous enseignez aux élèves ... comment éviter les réponses quasi verbatim qui correspondent à vos exemples?

Je pose des questions auxquelles les correspondances quasi verbatim de mon exemples.

Cette réponse est spécifique au domaine de l'informatique, conformément à la question du PO. Évidemment, la réponse est très différente si nous parlions d'un cours d'écriture créative ou quelque chose du genre.

Dans le domaine de l'informatique, il existe parfois une «meilleure façon» de faire quelque chose. Dans votre exemple, vous recherchez un tableau pour un objet spécifié. Dans la plupart des langages, les objets de type tableau ont une fonction find () . C'est la "meilleure façon" d'accéder au tableau. Je considérerais en fait que ce serait plus faux si un étudiant utilisait une autre approche pour parcourir un tableau à la recherche d'un élément spécifique.

Je vais aborder la nuance de l'utilisation de l'identifiant singleDocument à la recherche d'un fruit dans une gamme de fruits. C'est peut-être ce qui vous inquiète? Oui, idéalement, un étudiant devrait changer singleDocument en quelque chose comme singleFruit . Peut-être faire un commentaire parallèle aux élèves de la classe sur ces pratiques, car il importe en effet que nous nous soucions du code intelligible. J'en resterais alors là. Les étudiants qui persistent à utiliser de mauvaises pratiques de dénomination dans leur code finissent généralement par se tordre dans des projets plus longs et apprennent la folie de leurs manières.

J'ajouterai en aparté que lorsque j'ai appris à écrire du code informatique (Java), j'ai parfois fait des "erreurs" comme celle que vous montrez (pas de changement de nom d'identifiant). Cela était dû au fait que je ne comprenais pas complètement ce qui pouvait être changé dans le code et ce qui ne pouvait pas l'être. J'étais plus inquiète de terminer le projet et moins inquiète d'écrire du code vraiment propre. Au fur et à mesure que je devenais plus avancé, j'ai rapidement appris à résoudre des problèmes tels que la modification des noms d'identifiants pour qu'ils soient plus significatifs.

Il semble que le problème soit la correction de la sortie par rapport à la clarté du code? Dans ce cas, un système de notation systématiquement utilisé qui donne des points pour une sortie correcte et des points supplémentaires pour une utilisation correcte des noms de variables et de toute autre convention pertinente motiverait les élèves à prêter attention à ces problèmes, de la même manière que, par exemple, les professeurs d'anglais donnent / points d'ancrage pour la grammaire et l'orthographe, les professeurs de mathématiques pour montrer le travail, les professeurs de physique pour dessiner des diagrammes ...

S'ils ne sont pas des étudiants de première année, vous pouvez également motiver la pratique en leur demandant d'apporter du code des années précédentes et les amener à le modifier / l'étendre. Ou en fournissant des exemples avec la même fonctionnalité mais une lisibilité différente à modifier.

Pourquoi ne pas poser une question à choix multiples "laquelle des propositions suivantes fera x?" avec une version correcte et de légères erreurs dans les autres - peut même faire un marquage partiel en fonction de l'erreur.

J'ai ceci dans des fonctions Excel comme vlookup avec une liste qui demande quelle version renverra le nom ou le prix, etc.

Si vous marquez les réponses / projets / exercices des élèves (qui contiennent du code), une astuce consiste à laisser 5% à la qualité du code.

Cela signifie des commentaires propres, des noms de variables sensés et pas de code inutile . C'est mineur et il est peu probable que ce soit la limite entre l'échec et la réussite, mais cela aide à encourager les bonnes pratiques (et la plupart du temps les étudiants se rendent compte qu'il est en fait plus facile pour eux d'utiliser les bonnes pratiques!)

Lors du tutorat de mes camarades, il est de la plus haute importance qu'ils comprennent le concept de base derrière ce qu'ils font, sinon ils reviendront simplement me poser la question la semaine prochaine. Pour autant que j'en ai l'expérience, l'apprentissage n'a vraiment lieu que s'ils trouvent la solution par eux-mêmes au lieu de copier-coller. Cela demandera beaucoup plus d'efforts et de temps au début, mais le gain en vaut la peine.

En fonction de l'âge de vos élèves, vous devez les orienter vers la documentation d'une fonction / d'un objet et les laisser comprendre par eux-mêmes. S'ils veulent programmer correctement la lecture de la documentation est l'une des parties les plus essentielles, si cela est trop difficile (surtout au début), vous pouvez leur donner la signature de la méthode et une explication abstraite.

  Tableaux .find (item = > item.property == aiguille) haystack = .... item = .... aiguille = ...  

Dans ce cas, ils doivent au moins remplacer les noms de variables avec les noms correspondants et abstrait la partie affectation. Si des lambdas sont nécessaires, assurez-vous de les avoir couverts dans un exemple précédent et référencez-le, dans ce cas, vous pouvez même garder l'exemple plus général