Programmation : quand faut-il commenter son code ? Google s’invite dans le débat

Citation:

---

Envoyé par Patrick Seuret

Personnellement, je sais que je commente beaucoup, voire un peu trop, mais c'est aussi parce que j'explique d'abord les fonctionnalités de la méthode, ses comportements vis-à-vis des paramètres spéciaux (comment ma fonction répond-elle si le nombre est zéro, négatif, etc.) et après je déroule les étapes logiques sous la forme de commentaire dans le corps de la fonction. Ce n'est qu'après que je vais réellement coder tout cela et tant pis si mon bloc "éliminer les valeurs absurdes" est implémenté par 10 lignes de code ou un stupide appel "RemoveOutOfRangeValues()". Comme ça je peux refactoriser des sections de codes tout en m'assurant que je garde les bonnes fonctionnalités.

Ensuite, je ne crois pas qu'on puisse "trop commenter": d'abord ce qui est évident pour moi ne l'est pas forcément pour les autres qui reprendront mon code. Ensuite, il n'y a rien de pire que ces documentations qui n'expliquent pas comment se comporte une fonction. Que se passe-t-il si la fonction "CalculerAgeCapitaine" trouve -1, 0, 1000 ou s'il est mineur ? Dois-je traiter moi-même la valeur retournée, traiter des exceptions (au sens "catch()"), etc. Et la réalité, c'est qu'un manque d'information est pénalisant contrairement un à un code qui est un peu trop commenté (au pire on lit deux fois la même choses sous deux formes différentes et si on ne comprend pas l'une on comprendra l'autre)...

---

Je trouve ta méthode intéressante de poser d'abord les bases (le quoi) avant l'implémentation (le comment).
Mais plutôt qu'un commentaire ne serait-il pas préférable de découper/structurer le code.
Exemple : plutôt q'un bloc commenté "RemoveOutOfRangeValues", un appel à une fonction "RemoveOutOfRangeValues" qui elle sera (peut être) une fonction unitaire finale, qui s'occupe de l'implémentation dont on se fout complètement qu'elle fasse 10 ou 100 lignes car en effet on pourra l'améliorer au besoin. Au final en lisant le code qui contenait tes blocs commentés, en supprimant les commentaires on a en fait supprimer le code (du moins déplacer) le code qui polluait la lisibilité, tes commentaires étant devenus le nom des fonctions externalisées => gain en lisibilité, plus besoin de commentaires, fonctions unitaires = + maintenable, + testable, + réutilisable .... et ton code, sa structure, reprend complètement ta conception initiale (que tu avais faite via les commentaires), autant dire qu'il y a plus de chance qu'il fasse bien ce qu'il dit faire ;)

Bon code !

Citation:

---

Envoyé par gagaches

Quels beaux exemples, prenons le premier avec la variable explicative :

Code:

---

1 2 3 4

price = numItems * itemPrice; discount = min(5, numItems) * itemPrice * 0.1; finalPrice = price - discount;

---

Pourquoi est-ce le minimum entre 5 et le nombre d'items ?
Un petit commentaire explicatif ? :aie:

genre
//réduction totale = -10% prix unitaire, sur 5 articles au maximum

Et la valeur de discount unitaire en dur, très propre :mrgreen:

---

Joli troll :D

Je dirai pas de commentaire...enfin dans le code ;)

Une idée d'amélioration (pas la meilleure sûrement)

Code:

---

1 2 3

totalPrice = itemQuantity* itemPrice; totalDiscount = discountService.computeDiscountSwitchItemPriceAndQuantity(itemPrice,itemQuantity) totalDiscountedPrice = price - discount;

---

Là on sait que ce code appliquera une réduction en fonction du prix et du nombre d'article.

Restera à mettre en place un discountService dont l'instanciation sera "customisable" via properties (injection de dépendance).
Prévoir une instance de discountService nommée "tenPercentForFiveItemsMax" et la spécifiée dans ce properties.
Dans "tenPercentForFiveItemsMax" mettre finalement l'implémentation (le comment) dans la fonction computeDiscountSwitchItemPriceAndQuantity : return min(5, itemQuantity) * itemPrice * 0.1;

Citation:

---

Envoyé par deuz59

Là on sait que ce code appliquera une réduction en fonction du prix et du nombre d'article.

---

Un langage de 1970 défonce tout le monde: c'est le C :whistle: :whistle:

Code:

---

1 2	#define COMPUTE_PRICE_WITH_DISCOUNT(ITEM_PRICE, NB_ITEMS, DISCOUNT, MAX_SALES) \ (NB_ITEMS * ITEM_PRICE) - (min(MAX_SALES, NB_ITEMS) * ITEM_PRICE * (DISCOUNT / 100))\

---

Citation:

---

Envoyé par foetus

Un langage de 1970 défonce tout le monde: c'est le C :whistle: :whistle:

Code:

---

1 2	#define COMPUTE_PRICE_WITH_DISCOUNT(ITEM_PRICE, NB_ITEMS, DISCOUNT, MAX_SALES) \ (NB_ITEMS * ITEM_PRICE) - (min(MAX_SALES, NB_ITEMS) * ITEM_PRICE * (DISCOUNT / 100))\

---

---

Pour sûr que chaque type de programmation (procédurale, objets, fonctionnelle,...) et language plus précisément permettra des structurations spécifiques.
N'ouvrons pas un nième débat polémique sur "mon language est le meilleur" (ce qui est souvent vrai :) ), le but ici étant de s'aider et de s'appuyer sur les outils à notre disposition autres que le simple commentaire pour améliorer le code (et ces outils ne se limitent pas au langage, on peut entre autres s'appuyer sur des frameworks, des architectures, etc...)

Citation:

---

Envoyé par gagaches

sachant que le code est la traduction des besoins métiers, et donc de leurs spécificités ...
c'est le serpent qui se mort la queue.

---

Oui, "traduction"…*On veut savoir pourquoi tu a traduit comme ça, pas la signification…

Citation:

---

Il y a bien un élément de difficulté quand on fait un calcul partiel.
Et oui, le commentaire est fiable dans ce cas. Et bien sûr que j'ai gagné du temps.
Le dev a indiqué ce qu'il voulait faire ...
un coup d'oeil à la spec ensuite pour vérifier que l'implémentation est bonne et fin.

---

La vérification de l'implémentation dans ton cas, c'est entre le commentaire qui donne l'intention et le code en dessous, la spec, c'est pour vérifier que l'intention correspond à la demande… Bref, tu multiplie la charge de travail par 2…

Citation:

---

Ensuite, je veux bien voir la gueule de ton code, de tes versions et de tes git avec la mode actuelle du CI qui amène à faire 10x commits / jour sur la même anomalie/même bug, afin que les tests passent dessus.
Car oui, prétendre qu'une correction d'anomalie est unitaire à un seul commit, c'est faux.

---

Quelle mode ? Il y a un principe pour les SCM centralisés qui consiste à "commiter régulièrement" car leur méthode de gestion des changesets conduit à une gestion des merges manuelle lorsque ceux-ci sont trop complexes. Dans le cas des SCMs décentralisés, chacun est libre de commiter comme il veut mais il doit squasher ses commits avant de publier. Un gestionnaire des sources qui fait bien son boulot n'accepte jamais un pull request non squashé. Donc une correction d'anno (simple, gérable en un seul ticket) doit se résumer à un commit sur le référentiel. Et si il y a eu des aller-retour avec la validation, ça se réorganise aussi avant l'incorporation dans le Master…

Citation:

---

Sans parler des commit dégueulasses en mode "commit." sans détail, mais c'est un autre sujet.

---

On reste sur le sujet de la qualité, ici idem, si le responsable du référentiel a accepté un pull request non commenté, c'est lui qu'il faut voir.

Citation:

---

On va avoir potentiellement plusieurs commits successifs avec des évolutions partielles, rien que pour la recette unitaire et les tests et on va partir en archéologie dans les X dernières versions commitées pour comprendre de quoi ça retourne.

---

Idem, squash, ou feature branches…

Citation:

---

Après, oui, les systèmes de gestion de code source ou de gestion de configuration (git, svn, clearcase) et les outils de tracking d'issue associés (jira, redmine, clearquest, ...) permettent un suivi des ano/évol.
Par exemple, à l'époque de Clearcase/clearquest, on pouvait lors de l'équivalent du commit forcer l'association par un champ dans une liste déroulante à une issue créée dans clearquest qui portait et réalisait le diff global du code associée.
Donc code modifié forcément associé à une issue (ano, évol, ...) et avec un risque d'erreur "minime".

De nos jours, la liaison reste plus laxe et il faut rajouter des *commentaires* (:mrgreen:) dans le commit avec une référence à une issue des bugtrackers (jira, redmine, ...) pour faire le suivi des diffs.
une coquille dans le commentaire et la liaison ne se fera plus.

---

Nope… Toujours le cas. En fait, "avant", tu était peut être dans un contexte où les gens bossaient correctement (en admettant l'illusion que l'on puisse bosser correctement avec ClearCase…). Avant…

Bref, toi tu voudrait peut être voir mon code, moi je sais que je ne veux pas voir le votre.

Citation:

---

en admettant l'illusion que l'on puisse bosser correctement avec ClearCase…

---

C'est quoi ce troll ? :aie:

Je bosse avec Clearcase, mais aussi avec Git et je n'ai pas de penchant plus prononcé pour l'un ou pour l'autre.
Ce sont juste deux visions différentes et deux utilisations différentes.

Citation:

---

Envoyé par Patrick Seuret

Ensuite, je ne crois pas qu'on puisse "trop commenter": d'abord ce qui est évident pour moi ne l'est pas forcément pour les autres qui reprendront mon code.

---

Théoriquement, non, mais je vais juste rappeler le problème de maintenance…*Ton postulat est valable lorsque tu écris ces lignes, plus après 3 évolutions.

Citation:

---

Ensuite, il n'y a rien de pire que ces documentations qui n'expliquent pas comment se comporte une fonction.

---

À nouveau, même si ta remarque est juste, ici il est question des commentaires, pas de la documentation.

Citation:

---

Envoyé par deuz59

L'occasion de refaire un peu de pub pour cet excellent bouquin Robert C. Martin : "Coder proprement" ...."un commentaire utile est celui qu'on n'a pas besoin d'écrire"

---

Il y a un autre sujet précédemment où on m'a bien fait comprendre que R. Martin n'a rien compris à la vrai vie…

Citation:

---

Envoyé par deuz59

Un exemple tout bête : préciser l'unité de mesure dans une variable métrique (temps, distance, etc...).
Si j'ai une API qui me met demande un paramètre "time" (passons sur le fait que "time" reste hyper générique et pourrait être plus précis quand à la signification de la variable) et que je dois lire la doc pour savoir que c'est en secondes, pourquoi ne pas directement indiquer "timeInSeconds" !

---

D'une, ne pas oublier qu'une variable est typée (on suppose qu'on ne fait pas de JavaScript…*Oui, c'est un troll… :twisted: ) et qu'elle est dans un contexte et que ces deux éléments sont aussi des informations…
D'autre part, un contexte mérite un peu de stabilité, donc si plusieurs notions de temps sont présentes, on doit être dans un contexte où le temps est exprimé dans la même unité.
Enfin, ton "passons" est malheureusement très important. Si tu a trouvé un "time" qui manquait d'information, plutôt que de rajouter des descriptifs, un "secondsToWhatWePassedOn" ;) serait plus pertinent non ?

Citation:

---

Envoyé par deuz59

Restera à mettre en place un discountService dont l'instanciation sera "customisable" via properties (injection de dépendance).
Prévoir une instance de discountService nommée "tenPercentForFiveItemsMax" et la spécifiée dans ce properties.
Dans "tenPercentForFiveItemsMax" mettre finalement l'implémentation (le comment) dans la fonction computeDiscountSwitchItemPriceAndQuantity : return min(5, itemQuantity) * itemPrice * 0.1;

---

Oui mais ça n'aura un sens que si tout ceci est inclus dans un DiscountServicesFactory répondant à une implémentation d'une AbstractDiscountServicesFactory héritant d'une AbstractServiceFactory et implémentant l'interface DiscountServicesInterface. Si tu ne rajoute pas ça, je pense que le lecteur risque de s'y retoruver…

[QUOTE=foetus;9489026]Un langage de 1970 défonce tout le monde: c'est le C :whistle: :whistle:

Oui enfin, définir une fonction n'a rien de spécifique au C et au final, on retombe sur…*le post initial…

Citation:

---

Envoyé par transgohan

C'est quoi ce troll ? :aie:

Je bosse avec Clearcase, mais aussi avec Git et je n'ai pas de penchant plus prononcé pour l'un ou pour l'autre.
Ce sont juste deux visions différentes et deux utilisations différentes.

---

Moi si…*Justement pour avoir bossé avec les deux. D'une part, le modèle lock/unlock de Clearcase est plus que dépassé et inadapté à la plupart des développements modernes où il y a plus d'un développeur par équipe. Le highjack n'est pas une solution… Le coté centralisé est aussi très pénalisant aujourd'hui (ceci est aussi vrai avec des outils comme SVN). Enfin, les possibilités de gestion des sources (branches, flux…) sont quand même super limités…
C'est ce que j'en ai vu il y a 6/7 ans, le plateau passait un temps non négligeable à mettre en place son environnement de travail du fait de Clearcase. Ajoute qu'il bossait sous Eclipse et qu'il faut donc tout autant de temps à rattraper ses workspaces, voilà la productivité…

A mon avis,un code qui a les noms des fonctions, des variables qui ont sens est un code deja commenté.
-éviter les abréviations non standard,
-faire des noms des fonctions une phrases

Code:

---

bool is_empty_list(list*)

---

est compréhensible que

Code:

---

bool list_state(list*)

---

ceci

Code:

---

int nb_char

---

est mieux que

Code:

---

int nb;

---

il y a des bibliothèques qui n'ont pas besoin de trop d'explication dans leur documentation à part quelques avertissements (notamment gtk+ qui a une bonne façon de nommer ces fonctions à part quelques-unes ) du fait des noms fonctions, des enumarations, des types vraiments indicateurs qui sont explicites.
Un code facile à comprendre est code qui ressemble à son pseudo code. Car les pseudos codes dignes de leur noms sont explicitement mieux facilement compréhensibles.

Citation:

---

Envoyé par martopioche

Il y a un autre sujet précédemment où on m'a bien fait comprendre que R. Martin n'a rien compris à la vrai vie…

---

Je demande qu'à être convaincu par un mécréant :mrgreen:

Citation:

---

Envoyé par martopioche

D'une, ne pas oublier qu'une variable est typée (on suppose qu'on ne fait pas de JavaScript…*Oui, c'est un troll… :twisted: ) et qu'elle est dans un contexte et que ces deux éléments sont aussi des informations…
D'autre part, un contexte mérite un peu de stabilité, donc si plusieurs notions de temps sont présentes, on doit être dans un contexte où le temps est exprimé dans la même unité.
Enfin, ton "passons" est malheureusement très important. Si tu a trouvé un "time" qui manquait d'information, plutôt que de rajouter des descriptifs, un "secondsToWhatWePassedOn" ;) serait plus pertinent non ?

---

Entièrement d'accord, sauf que dans la vrai vie ce qui "mérite d'être" ne l'est pas toujours...ça reste un exemple simple mais assez parlant qu'on rencontre fréquemment
Pour le passons, je suis d'accord avec toi, c'était juste pour focaliser l'exemple sur la précision d'une unité, mais oui dans ce cas il est autant si ce n'est plus important de repréciser le "time", et certainement pas avec des commentaires/descriptifs, encore d'accord, mais avec une reformulation plus précise de la variable ;)

Citation:

---

Envoyé par martopioche

Oui mais ça n'aura un sens que si tout ceci est inclus dans un DiscountServicesFactory répondant à une implémentation d'une AbstractDiscountServicesFactory héritant d'une AbstractServiceFactory et implémentant l'interface DiscountServicesInterface. Si tu ne rajoute pas ça, je pense que le lecteur risque de s'y retoruver…

---

Ben oui justement l'informatique est complexe, traite de sujet complexes....les langages évoluent pour traiter toujours davantage de complexité, mais forcément dans le code tu fini par la retrouver...soit dans le design...soit dans un commentaire qui tente d'expliquer un code fouretout qu'on ne veut pas s'embêter à mieux structurer....perso je préfère la 1ère solution.
Si les langages dit "modernes" offrent des possibilités de design qui peuvent vite devenir incompréhensibles, on peut toujours essayer de coder en assembleur...pas sûr que ça soit plus compréhensible et surtout maintenable au final.
Après on code rarement seul et dans une équipe tout le monde n'a pas les mêmes degrés d'expérience/maturité, de connaissance des bonnes pratiques, etc....(ce genre de topic qui fait débat en est la preuve) au final parfois mieux vaut avoir tord à plusieurs que raison tout seul (si c'est pour designer qqchose de lisible qui colle bien au cahier des charges mais qui nécessite des connaissances techniques et un minimum d'effort intellectuel pour le comprendre mais que tout le monde veut coder "vite et bien" sans vouloir faire tourner ses neurones alors le code un peu complexe mais propre risque de devenir complexe et dégueu....autant revenir à du simple et dégeu du genre un gros bout de code bourré de commentaires inutiles !)

Citation:

---

Envoyé par free_01_binairy

Un code facile à comprendre est code qui ressemble à son pseudo code. Car les pseudos codes dignes de leur noms sont explicitement mieux facilement compréhensibles.

---

+1

Et surtout c'est un code qui a été pensé, réfléchi et qui fini par reprendre plus précisément le cahier des charges.
C'est de la conceptualisation : on reprend les concepts du cahier des charges en cherchant à être précis, notamment sur la nomenclature/terminologie pour être certain qu'on parle tous de la même chose, et notamment avec le client.
La panacée c'est quand le client demande une évol censée "rentrer" dans le moule actuel, mais que ça coince au niveau du code...c'est le code qui permet de mettre en avant des erreurs de conception/analyse dans le cahier des charges !

C'est du bon sens, de choisir de bons nom pour des variable, des classes, des fonctions, ...
il y a d'autres principes

const double *getData()
interdit de modifier le résultat, on peut écrire
double *getDataForModifications()
qui effectuera des opération en interne comme positionner des flags, pour permettre la modification

myFunction(myClass *myParam)
dit que l'on peut passer un paramètre NULL, puisque
myFunction(myClass &myParam)
l'interdit

etc...

Citation:

---

Envoyé par deuz59

sauf que dans la vrai vie ce qui "mérite d'être" ne l'est pas toujours...ça reste un exemple simple mais assez parlant qu'on rencontre fréquemment

---

Mais quelle "vrai vie" ? J'ai ça dans mon code, je vis dans un rêve ? Le sujet ici relève de la définition de bonnes pratiques, bien sûr que l'on ne rencontre pas toujours le cas idéal et que c'est le plus souvent c'est l'inverse, mais la démarche consiste aussi à "améliorer" la situation quand on peux.

Citation:

---

Pour le passons, je suis d'accord avec toi, c'était juste pour focaliser l'exemple sur la précision d'une unité, mais oui dans ce cas il est autant si ce n'est plus important de repréciser le "time", et certainement pas avec des commentaires/descriptifs, encore d'accord, mais avec une reformulation plus précise de la variable ;)

---

:ccool:

Citation:

---

Si les langages dit "modernes" offrent des possibilités de design qui peuvent vite devenir incompréhensibles, on peut toujours essayer de coder en assembleur...pas sûr que ça soit plus compréhensible et surtout maintenable au final.

---

Non mais qu'ils offrent des possibilités est une chose, mais commencer à faire des propositions de conceptions complexes sur un extrait de deux lignes de code, ça relève de la pathologie…*Quand je vois des proposition de passer par des classes dédiées avec moultes méthodes pour ne gérer que la récupération d'un paramètre…

Citation:

---

Après on code rarement seul et dans une équipe tout le monde n'a pas les mêmes degrés d'expérience/maturité, de connaissance des bonnes pratiques, etc....(ce genre de topic qui fait débat en est la preuve)

---

Tout à fait, mais sans parler de "bonnes pratiques", une équipe doit avoir des pratiques définies, des "règles/chartes de programmation". Même définies, tout le monde ne les applique pas (rien qu'un nouvel arrivant…). Une équipe devrait avoir un responsable qualité qui s'assure du respect de ces pratiques.

Citation:

---

au final parfois mieux vaut avoir tord à plusieurs que raison tout seul (si c'est pour designer qqchose de lisible qui colle bien au cahier des charges mais qui nécessite des connaissances techniques et un minimum d'effort intellectuel pour le comprendre mais que tout le monde veut coder "vite et bien" sans vouloir faire tourner ses neurones alors le code un peu complexe mais propre risque de devenir complexe et dégueu....autant revenir à du simple et dégeu du genre un gros bout de code bourré de commentaires inutiles !)

---

À nouveau, oui, même si on parle de "bonnes pratiques", il n'y a pas de recettes universelles et tout dépend du contexte.

Citation:

---

Envoyé par martopioche

Non mais qu'ils offrent des possibilités est une chose, mais commencer à faire des propositions de conceptions complexes sur un extrait de deux lignes de code, ça relève de la pathologie…*Quand je vois des proposition de passer par des classes dédiées avec moultes méthodes pour ne gérer que la récupération d'un paramètre…

---

Si il y a débat sur la compréhension et lisibilité d'un code à 2 lignes alors je ne vois pas où est le pb ? Je comprends ma proposition paraisse "too much", il y a peut être moyen de faire plus simple pour le même résultat (toujours en évitant le commentaire) mais c'est pas beaucoup plus compliqué de passer par un service dédié, et au final ça permet de préciser ce qu'on veut en réalité faire (au final on calcule bien une remise par rapport à une quantité et un prix et non simplement un prix ou une remise). On gagne en compréhension/maintenance en répondant au "single responsibility principle" (ok je frôle le fanatisme à Robert C Martin ^^).

Citation:

---

Envoyé par martopioche

Tout à fait, mais sans parler de "bonnes pratiques", une équipe doit avoir des pratiques définies, des "règles/chartes de programmation". Même définies, tout le monde ne les applique pas (rien qu'un nouvel arrivant…). Une équipe devrait avoir un responsable qualité qui s'assure du respect de ces pratiques.
...
À nouveau, oui, même si on parle de "bonnes pratiques", il n'y a pas de recettes universelles et tout dépend du contexte.

---

:ccool: je te rejoins, pas de règle universelle si ce n'est celle d'en définir par équipe/projet de façon collective et de s'assurer qu'elles soient appliquées

Citation:

---

Envoyé par martopioche

Quelle mode ? Il y a un principe pour les SCM centralisés qui consiste à "commiter régulièrement" car leur méthode de gestion des changesets conduit à une gestion des merges manuelle lorsque ceux-ci sont trop complexes. Dans le cas des SCMs décentralisés, chacun est libre de commiter comme il veut mais il doit squasher ses commits avant de publier. Un gestionnaire des sources qui fait bien son boulot n'accepte jamais un pull request non squashé. Donc une correction d'anno (simple, gérable en un seul ticket) doit se résumer à un commit sur le référentiel. Et si il y a eu des aller-retour avec la validation, ça se réorganise aussi avant l'incorporation dans le Master…

---

Bon, ok démasqué monsieur martopioche :mrgreen: et on va tourner en rond à forc eavec nos arguments.
Donc réponse longue (désolé à tous les autres pour le blabla)

Vu les termes et les arguments employés, tu as une trop bonne vision et maitrise de la gestion de configuration logicielle, des outils et de la chaine de dev et d'intégration.
Donc en profil ... pas un débutant (très loin de là)
responsable de gestion de configuration / responsable qualité / développeur ancien / ... ??


En vision théorique, on est en phase :
- La documentation et les specs doivent être portés dans un référentiel commun accessible et retrouvable facilement(soit par l'approche classique avec cdc, dat et spec fonctionnelles et techniques, soit par du agile/tdd/backlog, ou toute autre solution).
- cette documentation porte aussi la gestion des exigences
- tous les impacts côté développement sont reportés dans les spécifications métier & techniques
- le développement sera systématiquement lié aux issues générés dans l'outil de suivi du développeur (jira, redmine, clearquest, mantis, bugzilla, whatever :))
- sur le poste du développeur, les changesets seront isolés par issues avec des workspaces séparés
- les changements pour une issue sont donc bien associés à un seul changeset global
- les changesets sont portés sur des branches de la gestion de configuration par un rôle de delivery manager qui va gérer les différentes configurations


Dans ce beau monde idéal du développement, les commentaires du code commenceront sans doute par :
1/ une recopie des specs techniques à implémenter avec les requirements associés
2/ un remplacement au fur et à mesure des devs de ces specs par du code propre (variables, fonctions et classes bien nommées et typées)
3/ les commentaires resteront sur les éléments d'implémentation les plus complexes
- simplification d'un calcul spécifique
- optimisation d'un code qui rend sa lecture différente de la spec
- choix d'implémentation
- détails des erreurs/choix de compensation de librairies/framework utilisés
4/ on conserve des commentaires de lecture/bests practices qui restent minoritaires
(exemple typiques de commentaires que j'affectionne même si ça ne sert à rien en soi avec les éditeurs actuels, faire des commentaires de début et fin de boucles/fonctions/classes/fichier quand c'est trop long. ça améliore la lecture, vu que le vert se détache du code en blanc et montre une séparation, et d'être sûr dans l'écriture du code qu'on est pas gourré d'une accolade en C par exemple ... exemple totalement au hasard :)).

Et là, je pense que je t'ai rejoins dans ta vision.
Que je partage de manière un peu utopique maintenant.

Maintenant, dans le monde réaliste qui est le mien, je commente au maximum :
- docs pas mises à jour et pas maintenues malgré les demandes (notamment car séparation moa/moe et que la moa se fout des demandes de la moe, un exemple parmi tant d'autres)
- chaine de développement & de gestion de configuration pas/mal mis en place
- un manque flagrant de compétences de l'équipe dans l'utilisation des outils
- des décalages de niveau de dev conséquent entre les devs (avec des équipes distantes, par exemple)
- les devs ont 4 anos à traiter ? ils les font en une fois avec une recette globale, "c'est plus rapide" et "c'est chiant de changer de contexte, non mais je sais ce que je fais"
- ...

Bref, je commente comme si je devais me débrouiller avec rien d'autre que le code source dispo (ce qui est trop souvent le cas).

Citation:

---

Envoyé par deuz59

Une idée d'amélioration (pas la meilleure sûrement)

Code:

---

1 2 3

totalPrice = itemQuantity* itemPrice; totalDiscount = discountService.computeDiscountSwitchItemPriceAndQuantity(itemPrice,itemQuantity) totalDiscountedPrice = price - discount;

---

Là on sait que ce code appliquera une réduction en fonction du prix et du nombre d'article.

Restera à mettre en place un discountService dont l'instanciation sera "customisable" via properties (injection de dépendance).
Prévoir une instance de discountService nommée "tenPercentForFiveItemsMax" et la spécifiée dans ce properties.
Dans "tenPercentForFiveItemsMax" mettre finalement l'implémentation (le comment) dans la fonction computeDiscountSwitchItemPriceAndQuantity : return min(5, itemQuantity) * itemPrice * 0.1;

---

Citation:

---

Envoyé par deuz59

Je comprends ma proposition paraisse "too much", il y a peut être moyen de faire plus simple pour le même résultat (toujours en évitant le commentaire) mais c'est pas beaucoup plus compliqué de passer par un service dédié, et au final ça permet de préciser ce qu'on veut en réalité faire (au final on calcule bien une remise par rapport à une quantité et un prix et non simplement un prix ou une remise). On gagne en compréhension/maintenance en répondant au "single responsibility principle"

---

Découper à l'extrême est une mauvaise idée, car cela réduit la lisibilité.
De toute façon, l'architecture n'est pas figée. Si le besoin évolue de telle sorte que les réductions de prix deviennent plus complexes, on pourra, le moment venu, décomposer une fonction en plusieurs voire une classe en plusieurs, de manière adaptée au nouveau besoin, qu'on ne connaît pas aujourd'hui.
Le plus important, c'est de garder petites les classes et les fonctions et d'éviter de disséminer une même responsabilité dans plusieurs classes. Tant qu'elles restent petites, elles restent faciles à découper.

Citation:

---

Envoyé par martopioche

Moi si…*Justement pour avoir bossé avec les deux. D'une part, le modèle lock/unlock de Clearcase est plus que dépassé et inadapté à la plupart des développements modernes où il y a plus d'un développeur par équipe. Le highjack n'est pas une solution… Le coté centralisé est aussi très pénalisant aujourd'hui (ceci est aussi vrai avec des outils comme SVN). Enfin, les possibilités de gestion des sources (branches, flux…) sont quand même super limités…
C'est ce que j'en ai vu il y a 6/7 ans, le plateau passait un temps non négligeable à mettre en place son environnement de travail du fait de Clearcase. Ajoute qu'il bossait sous Eclipse et qu'il faut donc tout autant de temps à rattraper ses workspaces, voilà la productivité…

---

On bosse dans une équipe d'une dizaine de personnes, avec Eclipse...
Pas de souci d'unlock c'est géré par un plugin clearcase sous Eclipse, du coup c'est transparent.
La seule contrainte est en effet de devoir faire des checkin des fichiers en fin de développement avant de merger. Mais cela prend... Allez 2 minutes... :calim2:

Nous n'avons par contre pas de souci de mise en place d'environnement.
Le plus long est de compiler notre binaire, mais ça c'est dû à un compilateur super vieillot qui met une heure pour le générer... :aie:
Mais sinon sans parler compilation cela nous prend 2 minutes à tout casser...
Après si tu parles de mise en place de l'environnement from scratch, la mise en place de la vue dynamique + la configuration d'eclipse ça monte à 15-20 minutes pas plus.

Après oui c'est vieillissant Clearcase faut pas se le cacher, mais de là à le poignarder il y a un monde tout de même.

Citation:

---

Envoyé par transgohan

On bosse dans une équipe d'une dizaine de personnes, avec Eclipse...
Pas de souci d'unlock c'est géré par un plugin clearcase sous Eclipse, du coup c'est transparent.
La seule contrainte est en effet de devoir faire des checkin des fichiers en fin de développement avant de merger. Mais cela prend... Allez 2 minutes... :calim2:

Nous n'avons par contre pas de souci de mise en place d'environnement.
Le plus long est de compiler notre binaire, mais ça c'est dû à un compilateur super vieillot qui met une heure pour le générer... :aie:
Mais sinon sans parler compilation cela nous prend 2 minutes à tout casser...
Après si tu parles de mise en place de l'environnement from scratch, la mise en place de la vue dynamique + la configuration d'eclipse ça monte à 15-20 minutes pas plus.

Après oui c'est vieillissant Clearcase faut pas se le cacher, mais de là à le poignarder il y a un monde tout de même.

---

pour en avoir administrer, clearcase reste encore très lourd à mettre en place.
Les plugins sous eclipse facilitent la vie et j’appréciais les vues dynamiques.

Mais il faut se l'avouer, l'énergie (et le prix car c'est loin d'être gratuit) de mettre un clearcase/clearquest vs le sortir et gérer dans git offre en "~équivalent JH", le temps de travailler sur les hooks, sécurité et autre "best practice" dans la mise en place d'un workflow de développement.

Car, il faut avouer, ça reste plus simple de gérer une ano en production avec du git qu'avec du clearcase (au niveau commits/merges j'entend).

Citation:

---

Envoyé par gagaches

Bon, ok démasqué monsieur martopioche :mrgreen:

---

Démasqué ? Mince, toi, tu est un de ceux que j'ai fait souffrir… :twisted:

Citation:

---

on va tourner en rond à forc eavec nos arguments.

---

Vu la réponse, c'est une question de formulation et compréhension.

Déjà une chose : quand tu cite dans la "théorie" des choses comme :

Citation:

---

- sur le poste du développeur, les changesets seront isolés par issues avec des workspaces séparés

---

Quand je lis "issues", c'est de la maintenance. Or un dev, ce n'est pas que de la maintenance. J'ai bien écris pas que. La maintenance travaille sur des "issues", les devs sur des "features". Et non, ce ce n'est pas aussi binaire : un dev qui ne s'en sort pas, il va demander de l'aide à l'expert technique ou à un collègue qui, peut-être, fera une copie locale… Même avec de la théorie on ne peut pas limiter, pas exemple, les commits (ça, c'est toi qui voulait ne pas en voir une multiplication ;) ). Les principes que je défends doivent s'appliquer à l'ensemble du projet car l'issue que tu a corrigée aujourd'hui, la semaine prochaine, un dev qui intervient sur l'évolution l'aura sous les yeux.

Citation:

---

les commentaires du code commenceront sans doute par :
1/ une recopie des specs techniques à implémenter avec les requirements associés
2/ un remplacement au fur et à mesure des devs de ces specs par du code propre (variables, fonctions et classes bien nommées et typées)
3/ les commentaires resteront sur les éléments d'implémentation les plus complexes
- simplification d'un calcul spécifique
- optimisation d'un code qui rend sa lecture différente de la spec
- choix d'implémentation
- détails des erreurs/choix de compensation de librairies/framework utilisés
4/ on conserve des commentaires de lecture/bests practices qui restent minoritaires
(exemple typiques de commentaires que j'affectionne même si ça ne sert à rien en soi avec les éditeurs actuels, faire des commentaires de début et fin de boucles/fonctions/classes/fichier quand c'est trop long. ça améliore la lecture, vu que le vert se détache du code en blanc et montre une séparation, et d'être sûr dans l'écriture du code qu'on est pas gourré d'une accolade en C par exemple ... exemple totalement au hasard :)).

---

1 -> ben non…*Pas dans "le monde idéal"…
2 -> par principe, j'insiste sur une attitude "boy scout" : laisser un code sur lequel on intervient au moins aussi propre qu'il était lorsqu'on est arrivé. Uniquement un code sur lequel on intervient car on va le modifier, les tests de non régression font parti de l'intervention et permettront de s'assurer de l'absence de régression ce qui n'est pas garanti si on se dit qu'on va modifier un nom de variable en passant…
4 -> pour ta parenthèse, le problème de ton exemple "vert se détache du code en blanc" vaut pour ta config… Et ça peut n'être que du bruit que pour le lecteur…

Citation:

---

Maintenant, dans le monde réaliste qui est le mien
[…]
Bref, je commente comme si je devais me débrouiller avec rien d'autre que le code source dispo (ce qui est trop souvent le cas).

---

Il y a une différence entre affirmer "c'est mon monde" et "ce monde est trop souvent le cas". Je n'ai jamais écris que je vis chez les bisounours. Surtout parce qu'ils ne développent pas… Mais je ne vais faire de généralité d'aucune de mes expériences. Car déjà, il y a une différence énorme entre les outils à disposition et l'intention des équipes. Oui, j'ai vu des plate-formes avec une infra au petits oignons pervertie par une équipe qui n'en avait raf (j'ai cité plus haut le principe du squash, j'ai rejoins un projet où on m'annonçait une bonne pratique avec un "Git Flow", ça s'est fini avec une unique branche dev/prod' et commits à outrance comme tu les a cité) et à l'inverse une équipe qui essayait d'appliquer au mieux des principes avec une infra inexistante mais avec l'ambition que "ça ira mieux".

Le "monde idéal" n'existe pas, je n'ai jamais dit le contraire. Mais je fais une différence entre ce que devraient être les "bonnes pratiques" qui se sont montés efficaces et donc avoir une démarche en ce sens et avoir une pratique dont on doit "se contenter". Quand je parlais de "formulation et compréhension", c'est que je n'ai aucun problème avec quelqu'un qui affirme que "je rajouter la ref de l'anno car notre système de suivi est foireux" par rapport à laisser entendre que ce devrait être la pratique.

Citation:

---

Envoyé par transgohan

On bosse dans une équipe d'une dizaine de personnes, avec Eclipse...
Pas de souci d'unlock c'est géré par un plugin clearcase sous Eclipse, du coup c'est transparent.

---

Non mais que ce soit géré par un client, le problème n'est pas là. C'est tout le principe du lock/unlock qui aujourd'hui est simplement improductif…*Quand tu a juste 2 clampins qui ont par exemple à bosser sur 2 parties d'une page web et qu'il s'agit donc d'un template commun et le même contrôleur, que leur charge est estimée à une journée et qu'il faut que ce soit livré demain…*Il y a un problème…

Citation:

---

La seule contrainte est en effet de devoir faire des checkin des fichiers en fin de développement avant de merger. Mais cela prend... Allez 2 minutes... :calim2:

---

Ça fait plus de 5 ans que j'ai eu à y faire, non, mettre en place un environnement pour bosser sur l'actuel, c'est simple, tout ce qui sort des clous par contre, j'ai souvenir d'une sinécure.

Citation:

---

Envoyé par gagaches

Mais il faut se l'avouer, l'énergie (et le prix car c'est loin d'être gratuit) de mettre un clearcase/clearquest vs le sortir et gérer dans git offre en "~équivalent JH", le temps de travailler sur les hooks, sécurité et autre "best practice" dans la mise en place d'un workflow de développement.

Car, il faut avouer, ça reste plus simple de gérer une ano en production avec du git qu'avec du clearcase (au niveau commits/merges j'entend).

---

C'est ce qu'on avait observé…*Passé une période où il a fallu former les équipes à d'autres pratiques, ça a été le jour et la nuit…