Oui mais dans quel cas tu voudrais connaitre le "pourquoi"/savoir comment fonctionne l'implémentation ? A part modifier le code il y a pas de raison, et modifier un code sale même commenté c'est le meilleur moyen d'introduire des bugs.
Bah peut y avoir plein de raisons, même sans partir du postulat que le code est crade. Genre, simplement étudier le code de quelqu'un, ou savoir si justement tu vas pas faire de la merde en modifiant l'implémentation. Par exemple, tu pourrais penser que l'implémentation X serait plus performante que l'implémentation actuelle, le mec qui a écris le code en a conscience, mais pour les raisons A et B c'était pas possible / intéressante / viable / trop time-consumming / etc... et un jolie petit commentaire viens t'expliquer ça. ![]()
Le probleme qu'on a souvent avec les code est que les cas de bord ne sont pas bien gerer et pas bien clair. Si par exemple ton code prends un int 32-bit en parametre, tu peux penser qu'il va fonctionner sur tous les int possibles. Mais si la fonction a besoin de mettre le int au carre, ca veut dire que probalement toutes les entrees superieur a 2^16 ne vont pas etre calculees correctement. Et ca tu ne peux t'en rendre compte qu'en ayant une comprehension clair de comment la fonction marche ou une documentation precise de la fonction.
J'ai eu un probleme de format ce week end. J'ai recu des donnees geographiques ou des evenements sont identifies par une coordonnee precise et d'autres par une bounding box (4 coordonnees). Et bah les coordonees de point etait au format longitude,latitude et les coordonne de la bounding box au format latitude,longitude. Les meta donne ne disait pas qu'il y avait une difference.
J'ecris plein d'algo de graphe, et j'ai des algos qui marchent seulement sur certains types de graphes. Certains avec des conditions simple: oriente, non-oriente, sans cycle. Mais d'autre avec des proprietes pas evidente: haut diameter, scale free, clustering coefficient faible. Ce genre de detail, tu ne les aura pas en lisant le nom de la fonction, en regardant le type des parametres. Tu peux le comprendre en lisant le code, mais franchement sans documenter la fonction explicitement, 99% des utilisateurs vont se planter.
J'ai l'impression que j'ai pas été très clair, j'ai jamais dis que les commentaires étaient inutile et qu'on pouvait tout le temps s'en passer, je voulais juste faire remarquer que c'est pas uniquement en commentant son code qu'on aura quelque chose de bien, c'est une des étapes pour avoir du bon code mais c'est pas la seule, donc c'est pas "LA" base.
Évidement qu'on peut trouver des exemples où les commentaires sont obligatoire et irremplaçable, mais ça change en rien ce que je voulais faire remarquer à la base.
Le pigeon, j'ai bien compris ce que tu voulais dire. J'essayait d'elargir le discours.
C'est quelquechose que l'on entend beaucoup "pas besoin de commentaire, juste un bon code", ou bien "un code clair est plus important que de commenter parceque le code change et les vieux commentaire reste", ou encore "document juste l'interface et les details implementation deviennent inutile".
Mais dans la vraie vie et dans des codes complexes, comprendre comment et pourquoi une fonction marche est juste cruciale. Alors des fois tu as juste besoin d'obtenir un modele mental de comment ca marche et les details ne sont pas aussi important, mais des fois les details sont importants.
Et c'est un probleme qu'on a de plus en plus a cause de code et de framework pas documente ou mal documente. Et qui est franchement exacerbe depuis qu'on est atteint de framework-ite aigue. J'ai un collegue qui a perdu 10 jours a cause d'un detail de D3 qui n'etait pas documente et qui a fait partir 90% du jeu de donne qu'on essayait de visualiser a la poubelle.
Aaaaaah. J'ai enfin commencé à taffer sous UE4. Par contre, ce que c'est chiant le blueprint juste pour modifier une pauvre valeur dans un material. ![]()
https://youtu.be/jWrEkR5nwNE
Aujourd'hui, promis, je ne me "moque" plus des professeur de primaire qui disent que c'est fatiguant. On s'est improvisé prof pour montrer aux enfants comment fonctionne la programmation (élèves de CM2), et du coup on leur faisait faire des petits jeux android avec App Inventor (un truc de google et du MIT pour faire découvrir la programmation aux enfants)
ça ressemble à ça :
Donc on avait un groupe par heure de 8h à 16h avec 1h de pause entre deux, et c'est vraiment sportif. Il faut à la fois s'adapter à ce que l'enfant veut faire, tout en s'adaptant à leur comportement. Entre les tout timides tout calmes et les tous nerveux... Woaw ![]()
C'était vraiment sympa, je recommence demain, mais expliquer ça aux enfants, c'est pas évidant, surtout quand ils n'ont pas de notions basiques genre les variables ou ce genre de truc. Surtout que cet environnement est pas non plus ouf, et faire quelque chose sortant du cadre devient tout de suite plus compliqué (genre deux filles voulaient mettre un chrono pour faire le score maximum en 1 minute, hé ben ça prend du temps à faire, je m'y attendais pas
)
Enfin bref, tout ça pour dire qu'enseigner, c'est vraiment pas facile ![]()
Mon père est prof de primaire. J'ai jamais compris les gens qui pensaient que c'était un taff facile.
Je vois pas le moindre argument pour cette théorie. ![]()
Ben pour ma part je me disais "ouais c'est des gamins, ça va"... Ben nan ![]()
J'ai fais un stage dans l'école de mon père quand j'étais en 3ème. J'envisageais potentiellement de m'orienter vers prof de math à l'époque. Ça m'a convaincu de jamais faire instituteur. Les gamins sont juste infâmes, le niveau d'éducation a grandement baissé, le prof doit désormais avoir un rôle d'éducateur (la mongolerie suprême à mes yeux : l'éducation c'est les parents, le prof est là pour instruire), les parents sont contre toi car leur gamin est roi, et j'en passe...
ça ne vaut pas le coup de laisser tomber tous ceux qui veulent apprendre
Je dis pas que faut laisser tomber non plus. Juste, être prof, c'est pas la partie de plaisir que beaucoup de gens s'imaginent, où tu fais garderie, les élèves sont tous heureux d'apprendre avec un sourire, et le tout dans des paillettes roses. Faut une réelle passion pour faire ce métier, car c'est devenu un taff ingrat dans pas mal d'endroits. Personnellement, j'aime bien expliquer des trucs aux gens, mais si les mecs font pas d'effort, je vais pas me casser le cul non plus à les motiver. Si t'es prof, t'as pas spécialement le choix. ![]()
Oh le jolie débat que j'ai lancé
Des nouvelles d'ArK sinon ?
ça fait longtemps que je ne l'ai pas vu par ici ![]()
Oh le jolie débat que j'ai lancé
T'as pas fait mieux que le débat sur les commentaires que j'ai lancé en présentant mon github ^^
J'aime pas les gens qui "se vantent" (c'est pas vraiment le bon terme je sais mais je trouve pas mieux) d'avoir lancé un débat, j'trouve ça con en plus d'être majoritairement faux en général.
Le 10 octobre 2016 à 23:13:23 LEpigeon-888 a écrit :
Si le code est propre tu comprends ce que le mec veut faire sans commentaire, suffit de lire le nom des fonctions
Il faut du code propre ET commenté.
Sinon il se passe ce qu'il se passe toujours "je comprends pas, je réécris".
"J'aime pas les gens qui "se vantent" (c'est pas vraiment le bon terme je sais mais je trouve pas mieux) d'avoir lancé un débat, j'trouve ça con en plus d'être majoritairement faux en général."
C'était sarcastique, c'est pour ça que j'ai pas continué sur le sujet, t'en fais pas ![]()
Oui bon j'exagère un peu je sais mais faut dire qu'à force de voir des gens le faire je commence à devenir de plus en plus sensible à ce genre de commentaire et ça me fait rager de plus en plus vite.
Après là tout de suite j'ai rien contre personne ici, je sais bien que vous êtes tous sympas.
Non.
Lokilok
Oui oui, pas de soucis, je comprend ![]()
rhooo si on peut plus rigoler ! ^^