Posté le 31/12/2015 14:33
ne pas utiliser de boucle itérative (for), mais les remplacer par des boucles conditionnelles (while) ne pas utiliser la forme do { ... } while(...) mais seulement while(...) { ... } ne pas utiliser de switch, mais selon le contexte des empilements de if, ou des tableaux de pointeurs, etc pas plus de 5 fonctions par fichier pas plus de 25 lignes et 80 colonnes par fonction pas d'opérateurs ++, --, +=, -=, *=, /=, etc
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 221 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
Citer : Posté le 03/01/2016 17:13 | #
j'ai l'impression que cette Norme permet de coder relativement proprement sans t'expliquer pourquoi ton code est propre
La distinction entre ce qui est beau et ce qui ne l'est pas varie suivant les époques et les individus. Ce que l'on entend même par sentiment du beau diffère selon les penseurs et bien des cultures n'ont pas de mot qui corresponde exactement au beau du français actuel.
Comment peux-tu dire pourquoi un code est propre ? Il est propre parce qu’il est lisible, sans doute, mais ça reste subjectif.
Du coup, pas moyen de savoir pourquoi tel code est sale ou non, puisqu'il est décrété "sale" arbitrairement.
A partir du moment où tu instaure une règle, une loi, une norme, tu auras forcément des points de vue respecté et d'autres non.
Choisir, c'est renoncer !
On ne réfléchit pas selon la norme. On se remue les méninges pour trouver le bon algo, puis on le code (à la Norme).
À ce moment là, pourquoi se faire chier à respecter la Norme ?
Un algo n'a pas de langage ou de norme !
Les premiers algo datent de l'antiquité, comment veux tu qu'un langage de programmation, ou une norme, soit obligatoire pour réfléchir à la solution de ton problème ?
Matoux(42)
Citer : Posté le 03/01/2016 17:56 | #
PS: on devrait continuer ce débat IRL autour d'un macdall, ça serait plus sympa ; ) !
Si on pouvait réunir tout le monde. Après on peut te mettre contre Lephé qui est à Lyon aussi, et filmer
Ce débat est intéressant à la base, mais je trouve qu'il tourne pas mal en rond, à part que le sujet dérive et que les arguments objectivement fondés semblent commencer à manquer des deux côtés.
Si on recentrait un peu le sujet en essayant d'éviter de se répéter ? Je crois que le fond des opinions qui s'opposent dans ce débat tourne autour de ces différents arguments et questions :
→ Une Norme de code est favorable à l'apprentissage et est un outil pédagogique, parce qu'elle impose une grande rigueur.
→ Elle permet aux élèves de se concentrer sur l'algorithmique et de se comprendre les uns les autres.
→ Cependant, une telle Norme devrait être axée sur de la présentation et des règles générales peu restrictives (comme un nombre de ligne indicatif à éviter de dépasser), et ne pas amputer des parties du langage.
→ Une école dénuée de toute base mathématique pour l'informatique semble manquer de moyens de connaissance.
→ Un code respectant la Norme est-il nécessairement propre ?
→ Est-il nécessaire de bloquer tout les outils standards sous prétexte d'apprentissage, même une fois ces outils étudiés et compris ?
J'en ai peut-être oublié mais les deux dernières pages ne m'ont rien rappelé de plus flagrant. Ces arguments ayant déjà bien été débattus et répétés, on devrait peut-être éviter d'en rajouter une nouvelle couche pour faire avancer la discussion.
Citer : Posté le 03/01/2016 17:57 | #
Au moins quand un critique estime que quelque chose est beau; il argumente son avis. Là j'ai l'impression que ce n'est pas le cas. Enfin, c'est mon impression personnelle.
Je suis d'accord là-dessus, c'est ce que je dis : pourquoi ne pas utiliser les possibilités basiques du langage ? Je sais bien que le dernier GTA peut être codé en Brainfuck, mais pourquoi on le fait pas ? Sans doute parce que quand on traduit un algo en code, on essaie d'utiliser un langage adapté, ce qui fait qu'on le choisi tel que ses fonctions nous aident à produire du code clair. Pas pour dire "j'utilise Python mais on m'interdit d'utiliser les dictionnaires, hein, c'est trop compliqué pour moi", au lieu d'aller justement chercher comment s'utilisent ces derniers. Et encore, je doute que la complexité d'un "for", d'un "switch" ou autre soit un frein à l'apprentissage du C. Bien au contraire.
Citer : Posté le 14/07/2016 02:05 | #
C'est rigolo, parce que je suis plus trop d'accord avec le moi d'il y a quelques mois, et en même temps, si. Déjà, j'ai utilisé les labels d'une façon justifiée depuis (true story de ouf), et ensuite, j'ai beaucoup appris par moi-même hors de 42 parce que quand j'ai commencé à aller vers des projets plus complexes, la Norme a vraiment commencé à me dégoûter du code.
Les normes, on en connaît beaucoup, on vit avec (C89, C99, Python 3, et beaucoup d'autres). C'est utile en le fait que ça propose un ensemble cohérent de fonctionnalités, où les modifications doivent être techniquement justifiées. Généralement, les normes d'aujourd'hui (notamment pour tout ce qui est code) est pensé pour être le plus ouvert possible, et c'est à chacun de trouver son style, comment organiser son code, etc.
Seulement voilà : Planète Casio, c'est une communauté de personnes qui adorent apprendre par eux-mêmes. Le site lui-même est né comme ça. Et en face, ils se sont retrouvés avec le moi de l'époque, qui avait certes pas mal appris par lui-même, mais qui avait trouvé un cadre, celui de 42. (bon, ce fameux moi a depuis formé son propre cadre, hein)
Vous êtes une école qui veut proposer un cadre pour permettre à des étudiants de bosser mieux. Ces étudiants, vous partez du principe qu'ils n'y connaissent rien, qu'ils vont simplement vouloir faire fonctionner sans chercher à organiser leur projet, ou faire un Makefile (inclus dans la Norme de 42). Vous avez plusieurs possibilités :
- vous les laissez se démerder, quitte à ce qu'ils fassent de la merde et que le dialogue sur leur projet soit difficile parce que celui-ci est opaque ;
- vous donnez des conseils, organisez des conférences, mais n'imposez rien : beaucoup vont foncer vers la sortie sans prendre le temps d'apprendre l'organisation de projet et ses enjeux ;
- vous imposez une Norme restrictive leur obligeant à se pencher dessus.
42 cherche à avoir une bonne image pour que son style (école gratuite, apprendre par soi-même, etc) soit reconnu, pour que les élèves puissent aller quelque part par la suite, et perdure, donc les deux premiers choix sont très risqués de ce côté-là. La troisième devient alors la seule alternative viable. Maintenant, une Norme, oui, mais plutôt du genre restrictive ? Il vaut mieux. Vous voulez que les élèves qui connaissaient le moins sortent bons. Et les élèves qui faisaient ça d'une façon déjà correcte, mais différente ? C'est compliqué. Quelques options :
- vous pensez que cette école n'est pas pour eux, donc vous les oubliez ;
- qu'ils galèrent, s'ils sont bons ils s'adapteront ;
- vous faites du cas par cas, ce qui est extrêmement coûteux en ressources.
Et vous, si vous lanciez une école du genre, vous feriez comment ? À moins que vous n'en lanciez une différente ?
(désolé si la structure de ce message est confuse, il est deux heures du matin et j'ai sommeil)
Mon blog ⋅ Mes autres projets
Citer : Posté le 14/07/2016 08:58 | #
Ton utilisation des goto c'est la cas classique de la gestion des erreurs. Une autre manière de le faire aurait été d'avoir un seul label et d'y libérer tous les pointeurs non nuls. Ç'aurait également été plus souple au cas où les différentes erreur auraient fait plus que de s'accumuler mathématiquement. Et dans ce cas c'est un try/catch. Utilisation « raisonnable » donc, si tenté que ça existe.
La troisième devient alors la seule alternative viable. Maintenant, une Norme, oui, mais plutôt du genre restrictive ? Il vaut mieux.
Jusque-là je suis tout à fait d'accord. Utiliser une Norme de code plus restrictive que le standard pour former un cadre de travail est complètement justifié.
Si je devais lancer une école comme ça, j'opterais pour la seconde solution :
- vous donnez des conseils, organisez des conférences, mais n'imposez rien : beaucoup vont foncer vers la sortie sans prendre le temps d'apprendre l'organisation de projet et ses enjeux ;
À deux-trois détails près. Je pense que j'imposerais quand même deux-trois choses, un peu comme le standard. Pourquoi ? Parce que j'estime que c'est en laissant les étudiants choisir qu'ils vont eux-mêmes s'intéresser à ce qu'ils font et tenter de comprendre le fondement de leur programme. Ils vont se demander « boucle for(), boucle do/while() ou boucle while() ? » et ça va leur permettre de comprendre, à terme, l'utilité des trois. Bref, je pense que les bons élèves sont aussi ceux qui sauront se cadrer, même si on a besoin de les y aider.
J'ajouterai juste une remarque sur la solution choisie : norme restrictive il n'y a pas de mal. Mais obliger à mettre les opérateurs après les retours à la ligne dans les expressions muli-lignes, aligner le scope global (quoi ?!), et vérifier le code avec une machine à regex buggée est quand même relativement osé. Surtout, surtout, c'est retirer des parties du langage qui est impardonnable. Voilà ce qu'on m'a répondu à l'époque. Je vous laisse le paragraphe entier pour éviter les biais :
Première année ou pas première année, je ne vois pas ce qu'une école qui pense ses élèves incapables de gérer correctement trois boucles et un switch peut leur apprendre.
Citer : Posté le 15/07/2016 08:01 | #
Surtout qu'un switch bien espacé et bien tabulé est beaucoup plus lisible qu'une multitude de if/elif imbriqués, non?
Citer : Posté le 15/07/2016 08:16 | #
Quand les conditions if/else en question se ramènent à des égalités d'entiers (switch ne permet pas de comparer des objets plus complexes ou de tester des intervalles), il est certes plus lisible, mais il est surtout en temps constant.