J'allais le dire, on frise la branlette intellectuelle, le poncif d'un autre âge, au moins aussi pertinent que 'accolades: avant ou aprés le nom de la fonction ?' ou 'indentation: tabulation ou espaces ?'… le genre de croisade qui finit toujours mal, un peu comme lorsqu'on parle d'Apple.
Dès l'instant où ça a un effet bénéfique, en particulier la lisibilité donc compréhension donc maintenabilité OU - soyons fou - l'optimisation (si, si, y'a des gens qui choisissent VOLONTAIREMENT la performance sur la maintenabilité), il n'y a pas de raisons de se contraindre à ces règles discutables.
Elles n'ont de sens que lorsqu'elles répondent à une problématique, bien sûr que les good practices ou les design patterns sont fortement structurants, mais ça doit être avant tout des règles de bon sens, rabachées aux étudiants le temps qu'ils gagnent une expérience qui les aurait naturellement amené à utiliser lesdites règles.
[^] # Re: Julia
Posté par Graveen . En réponse au journal De l'enseignement de la programmation en classe préparatoire. Évalué à 10.
J'allais le dire, on frise la branlette intellectuelle, le poncif d'un autre âge, au moins aussi pertinent que 'accolades: avant ou aprés le nom de la fonction ?' ou 'indentation: tabulation ou espaces ?'… le genre de croisade qui finit toujours mal, un peu comme lorsqu'on parle d'Apple.
Dès l'instant où ça a un effet bénéfique, en particulier la lisibilité donc compréhension donc maintenabilité OU - soyons fou - l'optimisation (si, si, y'a des gens qui choisissent VOLONTAIREMENT la performance sur la maintenabilité), il n'y a pas de raisons de se contraindre à ces règles discutables.
Elles n'ont de sens que lorsqu'elles répondent à une problématique, bien sûr que les good practices ou les design patterns sont fortement structurants, mais ça doit être avant tout des règles de bon sens, rabachées aux étudiants le temps qu'ils gagnent une expérience qui les aurait naturellement amené à utiliser lesdites règles.
Non ?