Bonjour a vous,

Apres une discussion dans [1], plusieurs forumeurs ont dit qu'ils seraient heureux de participer a des commentaires de codes. Le but de ce topic est de poser les bases de l'organisation de nos commentaires.

Afin de pouvoir partager et echanger du code facilement, je suggere de mettre le code a disposition sur un plateforme de travail collaborative comme github [2]. Ce dernier permet de disposer d'un depot de code avec controle de version distribue. Ainsi chacun peut apporter une modification et explique en quoi cette modification rend le code de meilleur qualite. Naturellement, on peut emettre une opinion sur le code ou sur son organisation sans faire de modification sur le code.

Je suggere que l'on ne commente pas plus d'un programme a la fois a un rythme leger (environ 1 par mois ou tous les deux mois). Chaque programme sera associe a un topic separe disposant du tag [code review]. On choisira le programme que l'on discutera sur topic "[code review] organisation" (en repondant a ce message ci donc) apres que son auteur l'ai presente.

Opinions?

Bien a vous,

Erik

[1] https://www.jeuxvideo.com/forums/1-47-62279-1-0-1-0-comment-s-ameliorer-approfondir-ses-conn.htm
[2] https://github.com/

Je propose deux programmes differents que l'on pourrait eventuellement commenter.

Le premier est un genre de Qix [1]. C'est un jeu ou des balles rebondissent dans un espace rectangulaire. Le joueur peut ajouter des murs pour contraindre les balles dans un espace plus petit. Le niveau s'arrete quand une partie importante de l'ecran n'est plus accessible par aucune balle.

Ce programme est interessant pour commentaire car c'est un code qui a ete ecrit pour Nintendo DS. Il a ete developpe sur PC par l'utilisation d'une interface de programmation au dessus de la compatible ressemblant a l'interface pour nintendo DS. Plus tard le programme a ete porte pour nintendo WII en utilisant le mode frame buffer. Le code a ete ecrit entre 2007 et 2009. Il est en C++ et fait environ 2500 lignes de code.

Le deuxieme programme est spart[2]. C'est une bibliotheque utilitaire pour calculer une partition equilibre de charge de calcul positionnee dans un espace discret. Le code supporte des espaces a 1 et 2 dimension mais devrait pouvoir etre facilement adapte pour des espaces de plus grande dimension.

Ce code C++ est interessant a mon avis car il est tres algorithmiques. Il a ete ecrit avec pour etre rapide et modulaire. De la reutilisation de code et de la genericite de types est obtenu a l'aide de template C++. C'est un bon example de programmation defensive. Il dispose d'une large batterie de test.

Attendons d'avoir d'autres proposition. Puis decidons quel code nous commenteront en premier. Si un de mes codes est choisi, j'en mettrais une copie sur github.

[1] http://bmi.osu.edu/~esaule/Qix-website/
[2] http://bmi.osu.edu/hpc/software/spart/

Re-bonjour godrik,

Je me pose deux^Wtrois^Wplusieurs questions :
1) Quel genre de code va-t-on reviewer ? S'agit-il de nettoyer/améliorer/simplifier le code d'un débutant, ou d'un review sur du code déjà plus abouti ?
2) Est-il préférable de faire une review en collaboratif, ou vaut-il mieux plusieurs reviews individuelles ?
3) Github (en fait, git) ne risque-t-il pas de limiter les contributions ?
4) Quelle sera la forme finale de la review ? Comment faire en sorte que ça apporte le maximum aux programmeurs débutant, et que ça permette aux autres de se perfectionner ?

chris, voila de bonne question. Mon avis la dessus est la suivante:

1/ Je pense que ce qui est important est que l'auteur du code soit un local. C'est interessant de regarder le code d'autrui, mais si on a access a l'auteur, la review sera plus interessante pour ceux qui essayent de lire le code et celui qui l'a ecrit. A mon avis, on ne devrait pas faire de review sur un code qui n'est pas termine. Ce que je veux dire par la est que le code doit etre fonctionnel. Eventuellement avoir des bugs a droite, a gauche, mais dans l'ensemble etre fonctionnel. Ca evitera les reviews du type "mon code y marche pas debugger le pour moi" ou encore les "j'ai un projet a rendre dans 3 jours, finissez le pour moi". On fait un peu ces choses la deja sur le forum, mais je ne pense pas qu'on devrait le faire dans l'espace de [code review]. Apres, je pense que tous les codes sont bon a regarder. C'est certainement un processus nouveau pour beaucoup d'entre nous donc je pense que commencer sur des codes complet mais de taille raisonnable devrait etre nos premiere cible.

2/ Je n'avais pas pense a cette question. Dans mon esprit, la review etait collaborative. A la reflexion, Il est peut etre preferable de laisse une semaine ou 10 jours aux forumeurs pour ecrire une review ou faire des modification de code ou poser des question a l'auteur. Puis communiquer les reviews de tout le monde. Et discuter des reviews ou et le code de facon collaborative.

3/ J'ai pense a github parceque ca m'a l'air plus adapte que SVN et que beaucoup prefereront compare a tarball. Apres, on est pas oblige de faire du git. Peut etre peut on mettre en place un repository sur github et fournir un tarball du code initial.

4/ La forme finale de la review serait le thread qui a presente le code originellement. Il sera potentiellement accompagne de code ou patch contribues par les forumeurs.

De facon general, je pense que l'exercice sera assez heterogene. On a pas tous le temps systematiquement de contribuer du code, mais c'est ce qu'il y a de plus interessant. Mais lire un peu le code et fournir un avis dessus, ca peut se faire en quelques heures. On peu aussi contribuer de la documentation ou corriger des bugs mineur. Je pense que laisser les forumeurs contribuer en fonction de leur envie/humeur est ce qu'il faut faire ici. Aussi tout le monde ne peut pas forcement contribuer du code sur tous les projets. Si tu presentes un code en caml, je vais avoir l'air bien con...

Si on se limite a des codes aboutis, on aura peu de soumission. Donc je pense que prendre des codes des forumeurs, mais en forme terminal. Apres si les codes sont trop court, on risque d'avoir des codes peu interessant pour les plus avances du forum. Je pense que commencer sur des codes pas trop complique (~500/1000 lignes de C) peut nous permettre de rentrer dans l'exercice. Apres on peut alterner avec des codes plus gros.

As usual, comments are welcomed.

Je trouve cela interessant mais bien risque. C'est (malheureusement) pas developpez.com ici et cette histoire avec github semble bien compliquee et grosse a mettre en place pour l'utilisation casual et disparate que je vois personnellement en ce forum (je suis pas sur par exemple que l'on puisse veritablement parler d'une communaute "programmation" etablie sur jv.com).

Pourtant l'idee initiale reste toujours interessante. Moi je verrais plutot un truc un peu plus didactique, un topic principal dans lequel les gens peuvent humblement poster leur bout de code et avoir des feedbacks. On encouragerait les petits nouveaux (qui malheureusement non plus ne restent souvent pas plus longtemps qu'un seul post ejaculatoire) a participer et mettre leur code "en pature" sur ce forum.

My 2 cents.

Ok pour le point 1, sauf sur la notion de « code de taille raisonnable ». Combien de ligne cela représente-t-il ? Sachant que si on veut que ça tourne, il faut trouver du code régulièrement, et donc ça invite à des choses plutôt courtes (quelques centaines de lignes grand maximum, à mon avis).

Pour le point 2, j'avais en tête l'incompatibilité de certaines choses (la plus basique étant la façon de formater un code C qui varie d'un auteur à l'autre). Si on veut favoriser la diversité sur ce point, les reviews individuelles sont préférables.

Pour le 3, on peut aussi, dans le cas d'une review individuelle, juste se contenter d'un site web avec un wall (peut-être que ça intéresserait deepblue de faire ça ?). En tout cas, je rejoins tbop2, mieux vaut faire dans le simplissime au début, quitte à changer le système après quelques itérations si vraiment un gestionnaire de version s'avère nécessaire.

Pour le 4, ça n'est pas clair dans mon esprit que l'on converge vers un unique code final (cf le point 1).

« Si tu présentes un code en caml, je vais avoir l'air bien con... » je suis déjà en train de préparer mes 10kloc de x86, t'inquiète.

Au passage, un deal pourrait être de corriger certains devoirs après la date de rendu (ce qui nécessite de pouvoir vérifier que la date de rendue est passée, mais ça devrait pouvoir être possible).

PS: une autre idée, dans la même veine, serait de proposer un truc à coder et un langage, et de voir ce que les forumeurs ici arrivent à produire en une quinzaine de jours sur le sujet.

Chris_27 Voir le profil de Chris_27
Posté le 5 mars 2012 à 11:29:00 Avertir un administrateur
PS: une autre idée, dans la même veine, serait de proposer un truc à coder et un langage, et de voir ce que les forumeurs ici arrivent à produire en une quinzaine de jours sur le sujet.

Ca pourrait être sympa ça, on pourrait comparer nos solutions et voir ce qui est le mieux et différents points de vue.

Sinon l'idée originale de godrik me parait assez floue là

Elle me paraît aussi plue flou suite à ce thread.

Cela dit, je comprends son inquiétude vis à vis de la source du code. Il faut en effet éviter que ça se transforme en faisage de devoirs à la maison.

À ce propos, corriger un devoir peut, à la réflexion, aussi être délicat. Les enseignants sont en droit de vouloir recycler un devoir à la maison... mais si il y a un corrigé propre sur le net, cela ne devient plus possible. Du coup, c'est plus l'accord conjoint de l'enseignant et de l'étudiant qu'il faudrait avant de pouvoir reviewer du code issu d'un devoir.

PS: vous n'auriez pas un mot français bien pour mettre à la place de "reviewer" ?

http://www.wordreference.com/enfr/review

Pick them up!!!!

J'utilise tellement ce site que j'ai un raccourci dédié dans mon navigateur web.

Hélas, je n'ai rien trouvé de génial :
révision, rapport, analyse, diagnostic = c'est pas ça,
critique, examen = bof bof,
revue = un peu creux je trouve.

Je crois que revue de code est pourtant plus ou moins l'appellation officielle pour ce genre de choses en bon francais.

On dit bien "la revue de presse" c'est exactement la meme chose.

Déjà, parler de relecture (comme on le ferait pour un article de recherche) me choque moins que « revue ». Ensuite, il va y avoir un procédé d'amélioration qui n'est transcrit ni par revue, ni par relecture (ni par review en fait ).

avant propos:

"http://www.wordreference.com/enfr/review" suivi de "J'utilise tellement ce site que j'ai un raccourci dédié dans mon navigateur web."

Ptit joueur, j'ai un raccourci dans mon shell

Point principale.

Dans mon idee, je voyais "review" comme un "commentaire". Quelqu'un presente un code et les autres forumeurs emettent un avis, une critique sur le code en particulier. La critique pouvant etre illustre par un patch ou un ajout de commentaire dans le code, ou juste une discussion d'un aspect du code qui parait interessant. Le but est de fournir un retour a l'auteur plus qu'un code unique et corrige. D'ailleurs, je ne suis pas sur que deux forumeurs auront la meme opinion sur la notion de "code corrige".

Au niveau du public vise, j'ai peut comme le dit tbop2, que les debuttant ne restent pas longtemps dans le coin. Ils viennent avec un probleme et partent quelques jours plus tard. D'apres les stats de antre-jv [1], il y a moins de 20 personnes qui viennent regulierement qui ont poste dans le dernier mois. Je pense que vise pour les debuttant n'est pas judicieux parcequ'ils viennent et vont rapidement.

Si vous voulez commencer par des exercices que l'on envisage de faire en quelques heures, on peut commencer par ca aussi. Et voir ou l'on va. Des opinions sur des sujet d'exercices pour commencer?

[1] http://jvstats.forum-stats.org/stats/1/118/

Godrick sale thesard ! :D

C'est vrai que l'on se confronte un peu a une impasse la. Comme je t'ai dit personnellement je n'ai pas l'intention de vraiment consacrer du temps a reviewer du code mais je trouve tout de meme important qu'a la limite on prenne un peu plus le reflexe de reviewer un petit coup n'importe quel code de debutant qui passe dans le coin (puisque comme tres justement demontre: ils ne sont que de passage). Un bug debuggue c'est bien, mais de bonnes habitudes de travail et de code en cadeau bonus.... ben finalement c'est peut-etre tout aussi -voire plus- important.

Je serais deja plus pour une tout petite ligne a ajouter dans le topic epingle concernant la code review souhaitee et "expectable" quant a l'optique de ce forum.

J'aime beaucoup l'idée du code review, il faut dire que j'aime échanger avec mes collègues au boulot, et j'aime apprendre, corriger et être corrigé

Je crois aussi qu'il sera très intéressant de commenter le code du projet de l'un d'entre nous, car ça profitera à nous mais aussi à un projet, ce qui ne serait peut-être pas le cas si on faisait le code review du logiciel d'un inconnu, car on n'aurait rien amélioré au final à part une copie.

« Je pense que vise pour les débutants n'est pas judicieux parce qu'ils viennent et vont rapidement. »
à mon humble avis, c'est là un des problèmes ici. Il faudrait réussir à garder quelques uns des débutants/nouveaux qui viennent ici. Hélas, c'est infiniment plus facile à dire qu'à faire.

En fait, c'est un peu avec cet état d'esprit que j'ai été amené à l'idée de review de devoir (qui peut laisser le temps à l'OP d'apprécier le forum). Mais finalement, je trouve l'idée peu pertinente (cf mon deuxième message sur le sujet).

PS: l'idée proposée ici m'a fait repenser à ce thread https://www.jeuxvideo.com/forums/1-47-61487-1-0-1-0-caml-fonction-trop-couteuse-mieux-fair.htm </ma vie>

Pour moi l'idee etait de faire des reponse longue et construite a ce genre de requete:

https://www.jeuxvideo.com/forums/1-47-46404-44-0-1-0-printf-blabla.htm#message_62358