Envoyé par el_slapper
Tu es (ou je suis) déformé
Non, je pensais IHM, programmes, scripts, etc....
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Tu es (ou je suis) déformé
Non, je pensais IHM, programmes, scripts, etc....
Je suis un vieux programmeur par rapport à la plupart, et je peux vous dire une chose :
La seule chose dont vous etes sur et certain de toujours retrouver, ce sont les commentaires qui sont dans le code. Parce qu'avec le temps, les corrections de bugs, les optimisations, et toute la vie des programmes qui peuvent etre trés longue, le plus souvent les documents annexes sont perdus, ou alors ils existent, mais absolument plus personne ne sait où aller les chercher dans l'entreprise, que ces documents soit papier ou fichiers informatiques.
La documentation qui est la moins en phase avec la réalité du code, c'est les fichiers documentaires qui sont demandés pour accompagner le source, mais dont on ne pense pas ou on n'a pas eu le temps ou qu'on a oublié de re-corriger.
Si les documents/commentaires/informations/warning à l'intérieur du source, ne sont pas à jour, c'est de la responsabilité des programmeurs qui n'ont pas pris la peine de mettre à jour ce qui est à destination de leur propre caste. Pour moi, ce sont des programmeurs égoistes et je m'en foutiste, qui ne veulent pas prendrent la peine de mettre à jour les commentaires en même temps qu'ils mettent à jour le code.
Quand on est confronté de maniére fréquente à des programmes vieux de plusieurs années (plusieurs dizaines d'années parfois), ces commentaires dans le source sont indispensables. (Même si parfois, y a des commentaires inutiles).
Je vais même plus loin, au delà de l'entete de tout bloc de programme, pour décrire la fonctionalité, les paramétres d'entrées/sorties, selon l'importance du bloc, il peut etre judicieux de rajouter (selon les langages) des commentaires en apparence inutile, mais qui font apparaitre les structures d'un bloc.
C'est ainsi, que de maniére courante, j'ajoute parfois un commentaire, précisant que c'est la fin de la fonction/procedure/classe/méthode "bidule", parce que le bloc en question est un gros bloc, et que je ne me souviens plus forcément du nom de la dite fonction. Cela permet de mieux se répérer dans le code, dans le scrolling.
Et je fais la même chose, quand un bloc IF en cascade, un bloc CASE/SELECT, bref quand n'importe quel bloc est un gros bloc, je vais ajouter un commentaire (inutile à priori), mais permettant une relecture plus facile.
Si l'éditeur/framework/outil/atelier dans lequel vous écrivez votre code, le fait automatiquement pour vous, tant mieux, mais ce n'est pas toujours le cas.
Autant que possible, pour lisibilité, je met aussi une petite indentation raisonnable, pour une lecture rapide plus facile.
Je n'ai rien contre les noms long pour que ce soit plus compréhensible, mais il ne faut pas non plus, que cela devienne beaucoup trop long. Et dans de tel cas, j'en viens à utiliser des acronymes propres au programme en question. Au bout d'un moment en baignant dedans, les acronymes deviennent compréhensible. Par exemple desc_lg desc_sh (pour descripteur long, descripteur short ), parfois c'est un acronnyme anglais, parfois c'est un acronyme français selon les cas. Bien sur cela ne va pas etre immédiatement compréhensible pour celui qui ne connait pas le contexte, mais cela le deviendra à force. Par la présence des collégues qui lui expliqueront les significations, par éventuellement une petite notice explicative sur des usages/régles en vigueur pour le developpement.
Pire selon vous. OUI, il arrive que l'on laisse de maniére courante du CODE MORT en commentaires. Mais pas n'importe comment.
Sous la forme d'une note, un commentaire "FIX" ou "BUG" avec un numero identifiant, souvent une date pour connaitre quand cela a été fait. Pourquoi, une telle pratique ??
Parce que les FIX ou BUG, sont souvent faites en urgence, et qu'on veut pouvoir revenir dessus très rapidement pour remodifier si nécessaire. effets de bords, nouveau bug découlant de la correction... (Dans ce mode, où la production est bloquée ou attend avec beaucoup d'impatience, on n'a pas le temps d'écrire toujours super propre, on fait en urgence une réparation... par urgence cela va de correction immédiate impérative dans l'heure à au maximum correction dans la journée !! On fait au mieux, mais là on est super content d'avoir un code clair mais aussi un max de commentaires... )
Et là, y a une réalité que certains ne connaissent peut-etre pas, qui est que ces "BUG" ou "FIX" qui en principe devraient disparaitre, en otant le code-mort, perdure souvent pendant des années et des années... Parce que personne ne prend le temps de réviser le source, en otant un code mort qui n'a plus de raison d'etre en vu de l'ancienneté de la modification qui a été avalisé/testé/vérifié au cours des années, sans plus jamais ne poser de souci.
Pourquoi le code-mort perdure ?? Parce que c'est une perte de temps, que personne ne s'en préoccupe, et que le client n'a aucune envie de payer pour faire du nettoyage qui ne rapporte rien.
Bien sur, il arrive parfois, que des developpeurs de mon genre, sans même en parler, font du nettoyage de code, s'ils ont à intervenir de nouveau sur le bloc de source en question. Ou s'ils ont un temps mort. Mais si je fais une erreur par inadvertance lors d'un nettoyage, alors je risque de subir les foudres du client, pour avoir osé effectuer un nettoyage qui ne m'a pas été demandé, (mais dont le client va bénéficier par la suite dans 99% des cas où je ne fais pas d'erreur lors d'un nettoyage, mais le client ne va retenir que le 1% d'erreur... et ne surtout pas accepter de reconnaitre que son source est pourri par du vieux code-mort inutile de plus de 10 ans... parce que ces propres internes ou d'autres sous-traitants n'ont pas fait de travail qui va de soi... mais dont personne parmi les chefs et décideurs ne veulent en tenir compte)
La réutilisabilité du code ou le détournement de la fonctionalité initiale d'une méthode, fonction, sous programmes, bloc de code, est un gros serpent de mer, et souvent aussi une source inutile de complexité.
On se retrouve avec des énormes blocs de code (fonction/routine/méthode/classe ... ) qui font un peu tout et n'importe quoi, sont d'une énorme complexité, et avec un tas de paramétres d'entrées et de sorties. Autrement dit des blocs de code tellement complexes que cela prend bien plus de temps à comprendre ce qu'il fait, comment il le fait, comment l'utiliser, que d'écrire un nouveau bloc de code qui va remplir la fonctionnalité qui est demandée.
Soit c'est un bloc de code, qui a été concu dés le départ pour etre une fonction/méthode/sous programe/routine qui va etre appellé depuis plusieurs endroits et cela permet alors de bien factoriser mais modifier une routine existante pour que cela puisse servir de factorisation, est souvent mal fait.
De plus la factorisation ne doit pas engendrer des super-routines, fonctions, méthodes qui sont paramétrables en tout sens, et bien trop complexe à comprendre, mettre au point ou débugger. (Bien sur cela concerne ce que l'on developpe directement pour répondre à une fonctionalité demandé par les clients, et pas des API ou des structures de ce genre qui sont destinés par nature à etre polyvalente ou ultra-polyvalente)
Par habitude, quand j'utilise une astuce lié au compilateur ou au langage, ou une conversion de données implicites, je met toujours un commentaire spécial genre "Warning ASTUCE" et un justificatif d'une écriture de code non orthodoxe. Pour 2 raisons : un meilleur programmeur trouvera peut-etre un jour une façon plus simple/évidente que la mienne OU une nouvelle évolution du compilateur/logiciel rendra mon astuce incompatible en provoquant un bug ou rendant mon astuce inutile.
En résumé, si y a des fainéasses de dev, qui ne prenennt pas la peine de réviser/nettoyer le source, ou de mettre à jour les commentaires, ce n'est NULLEMENT un bonne justification pour refuser de laisser des commentaires et pire exiger que les autres ne laissent pas non plus de commentaire dans leurs sources.
Les jeunes dev oublient allégrement que les ateliers avec les doc automatiques, ou la génération de doc automatique, ne sont pas les seuls qui sont utilisés en entreprises. Et qu'il y a bien plus de sources qui n'ont pas été écrit avec ces ateliers ou générateurs !! Parce que ce sont des sources anciens, ou parce que cette génération automatique n'était pas maitrisés/utilisés.
Tu oublies le code en lui-même. Tel que tu le décrit, j'en comprends que le code et voué à changer alors que les commentaires non (ou beaucoup moins), donc la référence se trouve être le commentaire. N'empêche que le code aussi est là, qu'il change ou non.
Pour toi. Mais tout comme faire un code propre demande une certaine rigueur, tenir à jour les commentaires demande cette même rigueur. Mais les commentaires, personne ni rien ne sera là pour t'épauler dans cette tâche, alors que le code on a plein d'outils pour le tenir à jour. Détails ci-dessous.
Ce n'est pas plus le vieux code que le code fait avec des langages peu expressifs et très contraignants. Avec les langages haut niveau qu'on a aujourd'hui, c'est loin d'être un besoin aussi évident.
Au jour d'aujourd'hui, dans nombre de langage, tu peux recouper sans effet de bord tes gros blocs pour les réduire, en créant les fonctions associées aux différentes étapes. Cela te permet non seulement de ne plus avoir ce problème de gros bloc difficile à comprendre, mais aussi d'afficher bien plus clairement tes algorithmes en nommant correctement tes fonctions.
Je dis aujourd'hui car ce style de fonctions pour utilisations uniques engendrait des traitements mémoire supplémentaires (sauvegarde + restauration de contexte) qui ralentissaient l'exécution du programme. Aujourd'hui ce genre de chose c'est de l'ordre de l'optimisation effectuée par le compilateur (qui peut voir qu'une fonction n'est utilisée qu'une fois et donc peut remplacer l'appel par le code), donc plus besoin de s'en soucier.
Idem, découpage et nommage suffisent généralement à avoir un code compréhensible. Pour un vieux code utilisant des langages comme décris ci-dessus, je peux le comprendre, mais ceux tournant encore sous ces langages feraient mieux de les refaire avec des langages plus récents, flexibles et haut niveau. Les petits détails d'optimisation étant le boulot du compilateur.
La longueur des noms est une question de feeling, l'important étant qu'ils soient représentatif des données représentées. Acronyme ou non, ça dépend du contexte.
Pareil, aujourd'hui ça se gère très facilement avec de la gestion de version. Quand tu as un bogue et que tu sais qu'il n'était pas là avant, tu regarde les dernières versions de ta fonction. Non seulement c'est bien plus clair parce que tu vois le code exacte, et non un code en commentaire censé remplacer une portion de code actuelle qu'il faut retrouver soi-même, mais en plus tu ne surcharge pas la lecture de ton code avec des commentaires qui, si ça se trouve, resteront là et fera se poser des questions au futur lecteur (ancien code qui marche ? qui bug ? idée de code pour optimiser un truc ? etc.). Ce que tu décris très bien :
Les bons outils = pas de code mort = pas ce problème.
Réutilisabilité et détournement ne sont pas la même chose : réutilisabilité est la bonne pratique, détournement est la mauvaise (quand on interprète mal la notion de réutilisabilité). Un code réutilisable est un code dont tu as clairement identifié les entrées, sorties et le processus pour passser de l'un à l'autre, et donc tu sais que quand tu as ces entrées et que tu veux ces sorties, il te suffit de le réutiliser. Un détournement c'est quand les entrées/sorties/processus ne sont pas clairement identifié, et qu'on profite de cette ambigüité pour retoucher la fonction pour faire quelque chose de similaire mais différent sans s'en rendre compte. Le détournement intervient quand tu as un accroc de la réutilisabilité qui l'utilise au mauvais moment.
Tu peux avoir des fonctions complexes mais qui ne le sont que parce qu'on a pas clairement utilisé les concepts intermédiaires qu'elle utilise. Comme quand on fait une périphrase : plutôt que d'utiliser le concept, on met sa définition. Là, plutôt que d'utiliser des fonctions, on met leur code. C'est un problème de découpage.
Pour les arguments, le problème est le même : tu peux avoir des fonctions qui nécessite beaucoup de paramètres justement parce qu'elles sont haut niveau et qu'elle font des choses évoluées. Cela dit, ces arguments ont une logique, logique que tu peux représenter sous forme de structures de données au nom explicite. Dès lors une fonction qui prend 10 arguments peut se réduire à un ou deux arguments. Par exemple une fonction de calcul matriciel : plutôt que de donner en argument la matrice et avoir 10 arguments booléens différents pour dire si tu appliques 10 transformations possibles, à la place tu as une structure de données qui centralise ces booléens. Mieux, cela te permet de définir des fonctions qui te retournent des structures pré-remplies pour les cas les plus fréquents, comme ça même plus besoin de se demander ce qu'on doit configurer dans cette structure.
Coder est souvent mal fait, documenter est souvent mal fait, ... Soit on veut quelque chose de propre soit on s'en fiche, ça chacun choisit et a sa part de responsabilité. Après quand on veut quelque chose de propre, ça demande toujours un effort supplémentaire, le tout étant de savoir dans quoi on va le mettre. Factoriser, comme tout le reste, demande de bonnes pratiques pour être fait correctement. On en applique ou on fait ça à l'arrache.
Le but de la factorisation est de simplifier, pas de centraliser la complexité. Donc oui, si tu te contentes d’agréger sans simplifier la sémantique, ça n'a aucun intérêt. Mais ce n'est pas de la factorisation : tu es censé généraliser, donc avoir les même concepts mais potentiellement plus abstraits, pas agréger (ajouter des concepts). Encore une fois, ce n'est pas la technique qui est mauvaise, c'est l'utilisation qui en est fait.
Là je suis d'accord, et c'est le seul cas où j'estime que les commentaires sont nécessaire. Parce que la complexité du code est nécessaire pour obtenir ce qu'on veut, donc il faut la contrebalancer avec une description plus simple et surtout justifier cette complexité (dire que celui qui trouve quelque chose de plus simple n'oublie pas que son code doit aussi satisfaire ces points là).
Le but n'est pas d'empêcher les gens de mettre des commentaires, mais de faire comprendre que nombre de commentaires sont des indices qu'ils n'ont pas assez réfléchit avant de coder. Rien n'empêche de mettre des commentaires sur un code sur lequel on compte revenir plus tard, mais on ne peut pas considérer un code bourré de commentaires finalisé... et donc moralement vendable.
Ce n'est pas une raison pour dire que les bonnes pratiques d’antan doivent être gardées. Aujourd'hui il y a de nombreux outils accessibles pour se simplifier la tâche et des tutos plein le net pour apprendre à les utiliser. Si on aime coder sous notepad, c'est un choix, mais faut pas se dire qu'on n'est pas capable de faire un code propre parce qu'on utilise notepad : c'est parce qu'on a décidé de ne pas se donner les moyens de faire un code propre.
Coder ça s'apprend, les bonnes pratiques aussi, et utiliser les outils qui permettent de les appliquer en un clic aussi. Après on fait son choix, on apprend ou on joue les MacGyver. Coder sans les outils appropriés, c'est bon pour l'expérimentation et le bricolage. Quand la propreté du code devient nécessaire, on s'en donne les moyens, sinon on ne se plaint pas.
L'objectif n'est pas de critiquer du code existant en disant "c'est qui le coupable ?", mais de se mettre à jour sur les bonnes pratiques pour que les problèmes qu'on avait dans le temps ne se reproduisent plus. Un vieux code est un vieux code, mais ça ne justifie pas qu'on utilise encore de vieilles pratiques pour le faire évoluer, surtout quand on a montré qu'on pouvait faire mieux plus simplement.
@mathieu :
je te re-post un lien que j'ai déjà posté plusieurs fois :
Rewrites Considered Harmful?
en particulier sa conclusion :
A suggestion: If you have a very successful application, don't look at all that old, messy code as being "stale". Look at it as a living organism that can perhaps be healed, and can evolve. You can refactor, you can rewrite portions of the internals to work better, many things can be accomplished without abandoning all the experience and error correction that went into that codebase. When you rewrite you are abandoning history and condemning yourself to relive it.
Je résume ce que j'en comprends :
Hypothèses :
- le vieux code marche
- le vieux code est utilisé par beaucoup de monde
- le nouveau code ne marche pas si bien que le vieux
- le nouveau code est complètement séparé de l'ancien (assez pour être incompatible)
- il y a toujours moyen de prendre en main le SAV du vieux code soi-même
Conséquences :
- le manque de compatibilité fait que la nouvelle version ne répond pas aux besoins les plus complexes pris en charge par l'ancienne version
- il y aura probablement toujours quelqu'un derrière la vieille version, ce qui la fera perdurer
- les gens ne passeront au nouveau code que très lentement, voire pas du tout
Conclusion :
- il ne faut pas réécrire depuis zéro
Je suis parfaitement d'accord : réécrire depuis zéro sans faire attention à la compatibilité alors que c'est largement utilisé et qu'on n'a aucun moyen de forcer les gens à passer à la nouvelle version, c'est bien joli mais ça sert pas à grand chose pour la communauté en question.
Cela dit, on reste quand même loin de ce qu'on discute. La majorité des mes commentaires dans mon dernier post parlent de renommage et redécoupage, et en aucun cas de changer la logique ou le langage du code. Le seul lien que je vois c'est avec ça :
Les langages décris étant des "langages peu expressifs et très contraignants". On parle ici de besoin du programmeur : son langage ne lui permet pas d'exprimer ce dont il a besoin, et il doit donc recourir à des artifices ou séquences de codes compliquées pour faire ce qu'il veut.Pour un vieux code utilisant des langages comme décris ci-dessus, je peux le comprendre, mais ceux tournant encore sous ces langages feraient mieux de les refaire avec des langages plus récents, flexibles et haut niveau. Les petits détails d'optimisation étant le boulot du compilateur.
Si un très très vieux code fonctionne et répond aux besoins des utilisateurs, on n'y touche pas. C'est là la seule conclusion de ton article (un vieux code qui marche plutôt bien face à un nouveau encore en beta) mais le lien s'arrête là.
Si l'utilisateur n'est plus satisfait alors un programmeur y retouche. Si les besoins de ce programmeur pour corriger/maintenir ce code ne sont pas satisfaits, alors on passe à un autre langage. Et pouvoir mettre en place des fonctions de haut niveau avec suffisamment de clarté est un besoin à part entière. Soit on l'a, soit on l'a pas. Si on ne l'a pas, on n'a pas de problème et donc la remarque ne s'applique pas. Si on l'a alors on ne fait pas comme si le langage qu'on a sous les yeux était le seul existant et que tout devait être exprimé là dedans.
Et changer de langage ne veut pas non plus dire tout réécrire : rien n'empêche d'en réécrire le minimum dans le vieux code pour pouvoir utiliser un exécutable externe pour faire la partie du traitement qu'on veut, et de faire cet exécutable avec le langage le plus adapté.
Donc oui j'insiste, je ne parle pas d'un programmeur qui veut satisfaire son ego à recoder lui-même une appli parce qu'il trouve que son langage ou sa manière de coder est plus jolie. On n'est pas dans le domaine des oeuvres d'art : on a un besoin ou on ne l'a pas. Et si on a ce besoin, on fait ce qu'il faut pour le satisfaire, sinon c'est que ce n'est pas si important.
Est-ce qu'un code bien écrit a besoin de commentaires ? Dans la majeure partie des cas, non.
Est-ce qu'un code écrit dans l'industrie a vocation à être bien écrit ? Non plus, parce que le besoin d'avoir un code bien écrit est encore loin d'être naturel dans ce contexte. Que le langage soit vieux ou pas.
Donc c'est pas la peine de prendre comme référence des cas où la propreté du code est au bon vouloir de ceux qui trouveront le temps et la motivation de le faire. Pas le besoin => pas le problème => illustration incohérente.
Non, je pense que tu as raté l'essentiel
ça n'est pas "faire attention" ou quoi que ce soit...many things can be accomplished without abandoning all the experience and error correction that went into that codebase. When you rewrite you are abandoning history and condemning yourself to relive it.
C'est le principe même de ré-écrire..
Amélilorer, oui. Réécrire ponctuellement un petit bout, puis éventuelemnt plus tard un autre petit bout, oui..
Ré-écrire l'appli, non...
A moins de vouloir revivre les 10, 20, ou 30 ans d'améliorations, de corrections de bugs, de fine-tuning, etc etc... (et donc les faire revivre aux utilisateurs et aux payeurs)
PS: on sort un peu du sujet, mais tes 2 derniers posts m'ont fait penser à ça...
Réécrire une application a ses avantages, mais que si tu prends en compte l'expérience accumulée : refaire une conception qui tient compte des erreurs passées de façon à implémenter une théorie plus robuste et adaptée aux besoins. Si c'est réécrire pour dire de réécrire ça n'a aucun intérêt. Mais quand tu vois que tu as par exemple un concept A, à partir duquel tu dérives des concepts B, C, D, etc. et que tu te rends compte que c'est ton concept A qui est foireux et qu'il te faut remplacer par un concept A' qui t'oblige à tout revoir parce que les dépendances ne sont pas les même, il peut être moins couteux de refaire du début proprement que de chercher à faire des itérations qui te prendront trois plombes.
L'important est de ne pas perdre l'expérience accumulée. Par exemple si des tests unitaires ont été faits avec l'ancien code, les réutiliser dans le nouveau. Sinon utiliser l'ancien programme pour établir des cas de test : un résultat connus comme bon au niveau de l'ancien doit être bon aussi pour le nouveau.
L'argument de ne pas perdre l'expérience a du sens, mais celui de bannir la réécriture n'en a pas. Que ce soit dans le cas précis où on veut faire pareil mais en mieux, ou dans des cas différents où la réécriture a clairement tous ses avantages. C'est comme dire "il ne faut pas réinventer la roue" sans réfléchir plus avant : si tu veux améliorer tes compétences, il est primordial de réinventer la roue par soi-même pour bien en saisir les propriétés. C'est pas uniquement en apprenant la théorie que tu vas maitriser un domaine, la pratique est tout aussi importante et consiste principalement à refaire ce que plein d'autres on déjà fait avant toi.
Bref, on dérive certes, mais en soit les idées se rejoignent : que ce soit la réécriture, les commentaires ou les bonnes pratiques, chaque chose répond à un ensemble de besoins. Il est bien joli de dire c'est bien/pas bien mais hors contexte ça n'a tout simplement aucun intérêt à part générer du troll. Quand on dit "réécrire c'est pas bien" (ou son contraire), on précise le contexte dans lequel on l'applique, on ne fait pas passer ça pour une vérité générale. Le reste c'est pareil.
Au passage, la phrase que tu met en gras est bien joie, mais celle d'avant dit presque le contraire :
Qu'on soit bien d'accord : réécrire une application intégralement ou par petit bout, au final c'est la même chose si par petit bout ça revient à réécrire la majeure partie. Là où ça pêche, c'est le fait de ne pas tenir compte de ce qui a été appris dans l'ancien code. En réécrivant petit à petit, tu te concentres sur une partie du code, en réécrivant tout sur l'intégralité de la conception. Mais dans les deux cas, tu peux tenir compte ou non de l'existant et des leçons tirées. Même si tu fais par petit bout, tu peux tout à fait remplacer l'ancien code par un nouveau qui foire. C'est ce qu'on appelle une régression. Et ça tu peux l'éviter en ayant des tests appropriés.You can refactor, you can rewrite portions of the internals to work better, many things can be accomplished without abandoning all the experience and error correction that went into that codebase. When you rewrite you are abandoning history and condemning yourself to relive it.
Ton expérience, tu l'as dans tes tests (ceux effectués à la main avant, un peu plus automatiquement aujourd'hui). Et que tu raffines des petits bouts ou des gros, même l'intégralité, tant que tu as écrit tes leçons sous forme de tests, automatisés ou simplement documentés comme dans le temps, l'important il est là, pas dans le code. Le code, c'est l'expression de la solution à ton besoin. Ton expérience, c'est l'explicitation du besoin, que tu trouves dans le cahier des charges et dans les tests.
Bonjour.
Je pense que c'est une utopie de croire qu'un code bien commenté, va permettre au développeur qui reprends le code, de faire des modifications les doigts dans le nez.
Pour moi, les fainéasses, ce sont ceux qui pensent qu'en relisant des commentaires, ils vont s'approprier le code sans avoir fait tout le cheminement du précédent développeur, et toutes les heures de travail/réflexion/connaissance qu'il a passé/acquis. Ils pensent qu'un commentaire peut résumer des heures/années de travail et de connaissance... Le rêve.
Quand je lis la théorie d'Einstein sur la relativité, je suis incapable de comprendre le concept et d'expliquer la formule. Quand je lis des commentaires de développeurs, je ne comprends rien non plus. Le code, ça parle plus, et il faut s'approprier le code, et découvrir le cheminement du précédent développeur. L'informatique, ce n'est pas pour les fainéants, en effet.
Ceci dit, quelques commentaires par ci par là dans le code, ça peut toujours aider.
PS: je n'ai jamais corrigé un bug en lisant un commentaire...
@moldavi : si les commentaires que tu lis ne t'aident pas à comprendre le code plus rapidement ou plus en profondeur, c'est que ce sont de mauvais commentaires, ce qui ne remet pas en cause la nécessité d'en écrire des bons. Ou alors c'est que tu n'as jamais travaillé sur un projet assez gros ou bien dans une équipe suffisamment pro.
@Matthieu Vergne : je serais curieux de savoir quelle expérience du développement informatique "grandeur nature" tu as réellement pour affirmer autant d'âneries ? En étant en plus aussi sûr de l'infaillibilité de tes raisonnements et de ta manière d'argumenter ? (détail qui ne me donne pas envie, surtout à l'heure qu'il est, de contre-argumenter point par point)
Ce que disent Souviron34 et l'article qu'il a mis en lien, c'est qu'en décidant de tout réécrire, fût-ce en faisant de meilleurs choix que ceux de l'ancienne version, on suicide le projet... pour la simple raison que tout un tas de subtilités de l'ancien code, aussi affreux soit-il, vont nous échapper, y compris tout plein de corrections / évitements de bugs et de détails de mise au point délicats qui ont nécessité des années et des années de travail et de réflexion. D'où, précisément, des régressions à n'en plus finir que tu souhaites -- et que nous souhaitons tous -- éviter.
Donc réécrire, oui, mais pas trop. Réécrire from scratch un truc vieux de trente ans et bien stable, c'est risqué et ça fait perdre beaucoup de temps et d'argent (jusqu'à pouvoir faire couler une boîte peut-être), même si le codeur tout jeune tout juste sorti de la fac est convaincu d'être infiniment mieux outillé et plus intelligent que le dinosaure qui avait écrit les toutes premières lignes de code du projet. Tout informaticien un peu expérimenté sait cela.
Si un code n'a pas besoin de commentaires, ce n'est pas parce qu'il est bien écrit, mais parce qu'il ne fait rien de bien compliqué. N'importe quel algorithme ou module, ou même fonction complexe, comme il en existe forcément dans n'importe quelle application de la vraie vie réelle, aussi bien écrit soit-il, a presque toujours besoin de son lot de commentaires.
Sans compter qu'avec les années d'expériences, l'informaticien découvre régulièrement de nouvelles utilisations intéressantes des commentaires dans le code, et a peut-être tendance à en mettre de plus en plus alors qu'il code de mieux en mieux. Personnellement je n'ai jamais beaucoup commenté le code que j'écris, mais j'ai tendance à écrire un peu plus de commentaires maintenant que quand j'ai écrit mes premiers programme au début des années 90... et surtout mes commentaires d'aujourd'hui sont beaucoup plus utiles, en fait ce sont presque toujours des commentaires qu'il est impossible de remplacer par du code. Je veux dire par là que même en réfléchissant mieux aux noms de fonctions et compagnie et / ou en écrivant dans un langage très expressif il n'y a pas moyen de faire aussi bien que le commentaire qui me vient à l'esprit. Mais peut-être suis-je tout simplement un programmeur médiocre.
Bref, l'idée qu'un code bien écrit n'a pas besoin de commentaires, idée archi-fausse trop souvent exprimée en ces lieux (je suis inscrit depuis peu de temps mais cela fait des années que je vous lis), est surtout une idée de programmeur encore inexpérimenté qui surestime totalement son propre niveau dans l'art d'écrire du bon code. "Le code que j'écris est si génial que les autres le comprendront même si je n'ajoute aucun commentaire". Ben voyons.
Il y a aussi un moment où tu parles de logiciels qui permettraient d'appliquer toutes les "bonnes pratiques" (une expression qui ne veut rien dire et que je méprise presque autant que celle qui dit que programmer c'est "pisser du code") en un seul click. Je serais curieux de savoir de quels logiciels tu parles, parce qu'à ma connaissance une telle chose n'existe pas, à moins qu'on parle de "bonnes pratiques" qui sont en réalité très arbitraires et qui changent tous les deux ans avec les modes, les EDI et les frameworks...
Pour finir j'aimerais bien savoir quels sont les langages super-expressifs dont tu parles sans oser les nommer (pour quelle raison ?) et qui seraient la panacée. Si tu veux convaincre le monde entier qu'il faut réécrire tout le vieux code qui existe en C ou en Cobol dans un langage comme Haskell ou Ocaml (j'ai vu juste ?), je pense que tu vas bien te couvrir de ridicule. (et c'est moi, grand adorateur de Lisp, qui te le dis)
Non, je pensais à Java, mais même si j'y ai pas touché depuis longtemps, je ne mettrai pas le C++ hors course. Cela dit, si je n'ai pas donné de nom, c'est parce qu'il n'y a pas de langage qui soit suffisamment expressif pour tous les cas. De la même manière qu'il n'y a pas de logique (formelle) universelle, on utilise celle qui nous permet d'exprimer le mieux les éléments dont on a besoin. Si tu est capable d'exprimer tes besoins sous forme d'un diagramme de classe, alors part sur un langage orienté objet. Si ça passe mieux sur du fonctionnel (je suis pas connaisseur à ce niveau là donc je ne m'avancerai pas plus) alors va pour les langages qui y correspondent.
Mon expérience est ce qu'elle est. Je n'ai pas l'expérience d'un senior pour me permettre de dire allègrement "vous pouvez dire ce que vous voulez, moi je sais parce que j'ai vu". Mais si tu préfères juger sur la couverture plutôt que sur le contenu, tu as mon nom complet et mon occupation actuelle, cherche-le sur linkedin. T'auras mon CV.
Ma théorie est celle que je décris, et la pratique qui me donne confiance en cette théorie est celle de plusieurs années qui m'a fait passer, tout comme toi, de pas de commentaire et un code naïf à des commentaires par-ci par-là pour compléter mon code naïf, puis de plus en plus de commentaires pour compléter ce code qui s'améliorait au fur et à mesure que mes commentaires me faisaient prendre conscience de ce que je voulais vraiment coder, puis de me rendre compte que mes commentaires finissaient par être directement codable pour au final coder de manière à ce que ce soit au plus proche du langage nécessaire. Aujourd'hui, quand j'implémente un algo, je fais du pseudo code, et quand je fais le source je copie-colle l'algo en réorganisant les morceaux pour que le langage puisse le prendre, par exemple remplacer un :
par un :
Code : Sélectionner tout - Visualiser dans une fenêtre à part V <- V U {x}
Avec un nom pertinent pour bien montrer le rôle de l'ensemble, par exemple "vertices" pour un ensemble de vertex, il n'est pas difficile d'avoir un code clair. Encore faut-il avoir une idée claire de ce qu'on veut implémenter. Les traitements complexes dans mes algos sont découpés en fonctions aux noms explicites, ce qui se traduit de la même manière dans le code source.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
Je ne dis pas que c'est facile ou trivial. Je sais par quoi je suis passé et la rigueur nécessaire pour arriver à m'y tenir. Et le respect de deadlines est probablement ce qu'il y a de plus incompatible quand on a un objectif de qualité comme celui-là. Néanmoins, ce que je peux voir par ma propre pratique et par les codes que j'ai déjà du reprendre ou librairies que j'ai dû utiliser, je vois bien qu'il y en a des clairs qui n'ont pas besoin de commentaires et d'autres dont on espère que les commentaires décrivent bien ce qu'on lit. J'ai déjà lu des bouts de code où le code était parfaitement clair alors que les commentaires me portaient à confusion.
Enfin, la question étant de savoir si un code bien écrit a besoin de commentaires (et on l'a déjà dit, on ne parle ni de documentation comme de la Javadoc, ni de code ultra commenté pour faire un tuto), de ce que j'ai pu voir la réponse me semble évidente : en dehors d'optimisations pointues visant à exploiter des propriétés subtiles du système implémenté, il est inutile d'utiliser des commentaires si le code est bien écrit. Le code peut parler de lui-même.
Et tous les contre arguments que j'ai pu lire, soit sont hors contexte (e.g. on n'a pas le temps d'écrire du code bien écrit, on le sait, et donc on fait sans et on complète avec des commentaires, dès lors on ne peut pas l'utiliser comme exemple pour parler d'un code bien écrit) soit se réfèrent à des cas auxquels j'ai déjà fait face et où j'ai pu appliquer des alternatives propres (e.g. gros blocs de fonctions, nombreux arguments). Donc à moins que tu me donnes un exemple de code :
- mal écrit
- qui ne rentre pas dans la catégorie très spécifique citée ci-dessus
- qui ne peut pas être bien écrit sans commentaires
mon avis ne changera pas. Parce que mon expérience, aussi limitée soit-elle, m'a confortée sur cet avis. Il ne s'agit pas de dire les choses avec une tournure quasi-philosophique qui a l'air cool ou de citer un article de quelqu'un d'autre qu'on a bien aimé pour avoir du poids. Pour re-citer souviron34 : "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Bonjour.
C'est simple, tu me refais le documentation sur le principe de la relativité d'Einstein. Je la lis, et je te dis si je comprends ta documentation, et donc la relativité d'Einstein... Si je suis ton raisonement, Einstein a mal documenté sa théorie...
Un programme, c'est tout un cheminement intellectuel, petit/gros projet. Et jamais les commentaires ne pourront relater ce cheminement intellectuel.
Ce n'est pas parce que tu lis la documentation sur la relativité d'Einstein que tu comprends la relativité. Je considère que c'est la même chose en développement.
De plus un développeur écrivant un commentaire, qu'est-ce qui dit qu'il a les compétences d'un écrivant compréhensible par tous les êtres humains...
Sur la même idée, un code dont tu ne connais même pas la théorie qu'il tente d'implémenter n'a pas vocation à être compris. Mais si tu connais la théorie, un code bien écrit est un code qui doit représenter de manière évidente cette théorie. D'où l'idée de pouvoir copier-coller ses algos. Si tu implémentes une liste chaînée, un code bien écrit doit utiliser les même termes que ta théorie (liste, chaîne, etc.). Mais quelqu'un qui ne sait pas ce qu'est une liste chaînée n'a pas vocation à comprendre ton code, ce qui est parfaitement normal. La documentation est là pour dire quelle théorie tu implémente, le gars lit et comprends, éventuellement va en lire un peu plus sur le net, puis reviens lire ton code en se disant "ah ben oui, c'est ça".
J'avais un prof d'algorithmie qui disait, à peu de chose près
Je n'ai jamais été en mesure de le contredire.Créez un bon algorithme que vous pouvez "simuler" par vous même pour vous assurer qu'il tient la route, utilisez la bonne méthode pour représenter cet algorithme (parce que, bon, le flowchart, c'est pas forcément ca), et vous aurez quelque chose dont la traduction est quasi automatique.
Si, lors de l'écriture du code, vous suivez exactement la logique indiquée (sous entendu : que vous ne modifiez pas la variable A alors que c'est B qu'il faut modifier), la première compilation réussie (parce que bon, on oublie systématiquement une lettre dans le nom d'une variable, un fichier à inclure ou un point virgule en fin d'instruction)vous donnera un programme qui fait ce que vous attendez de lui.
L'algorithme est parfois perfectible parce qu'il y a parfois des méthodes "plus efficaces que d'autres" pour atteindre un objectif identique, mais là n'est, malgré tout pas le problème
Mais le fait est que si tu arrives à mettre au point une logique qui est en mesure d'expliquer à quelque chose "d'aussi bête qu'un compilateur ou qu'un ordinateur" ce qu'il doit faire, qui pourrait, à la limite, être transformée en code par une dactylo à qui l'on a expliqué les règles de "traduction", pour ne pas dire par une machine qui ces appliquerait règles de traduction à la lettre, la logique en elle même est suffisamment simple pour que n'importe qui puisse s'y retrouver si tant est que l'on utilise des noms cohérents et en rapport avec le sujet traité.
C'est beaucoup plus facile à faire, je te l'accorde, sur un programme qui ne contient que dix fonctions que sur un projet composé de plusieurs dizaines de milliers de lignes éparpillées parmi un nombre impressionnant de classes.
Mais la difficulté ne vient pas du code en lui-même, ni même des différentes logiques suivies à différents endroits. La difficulté vient généralement du fait que, plus un projet est complexe, plus il est difficile d'avoir une vue globale de toutes les interactions et de toutes les implications suivies par les logiques individuelles.
Le gros problème vient, selon moi, qu'énormément de développeurs écrivent leur code "à vue", sans avoir pris la peine de se poser pour déterminer quel serait le chemin le plus correct pour relier un point A à un point B, en avançant "pas à pas" et en réfléchissant finalement aux problèmes "au moment où ils se posent".
Dans de telles conditions, il n'est pas étonnant que les commentaires deviennent indispensables pour arriver à se rappeler de "pourquoi on a fait telle chose à tel moment".
Un code bien écrit, c'est d'abord un code qui applique une logique clairement définie, et non une logique où l'on a l'impression que le développeur à réfléchi à ce qu'il devait faire entre chaque instruction
Puis, c'est un code qui sépare clairement les différentes étapes : s'il faut une fonction qui fait le café, la vaisselle, la lessive et qui sort le chien, cela signifie qu'il y a une fonction pour faire le café, une autre pour faire la vaisselle, une troisième pour faire la lessive, une quatrième pour sortir le chien et une dernière pour faire le tout dans l'ordre déterminé.
Ensuite, c'est un code qui utilise des noms de variables, de structures ou de fonctions au minimum cohérents avec le domaine pour lequel il est écrit ou avec le but de la fonction, de la variable ou de la structure qui est créée.
Enfin, c'est un code structuré (indenté) de manière à pouvoir identifier facilement les différents blocs d'instructions dont il est composé.
Le fait qu'un code soit bien écrit ou non n'est jamais rien de plus que l'expression de la volonté de celui qui le rédige! Ce n'est ni une question de contenir des commentaires (s'il respecte ces quelques points, ils devraient se limiter au stricte minimum), ni une question de temps (cela ne prend pas plus de temps de nommer correctement ses variables que d'utiliser les différentes lettres de l'alphabet),ni une question de budget : De nombreux codes ont été (sont sans doute encore) volontairement mal écrit parce que leur développeur n'était soit pas motivé à l'écriture d'un code correct, soit persuadé que c'est une manière de se rendre "indispensable" et donc de garder sa place.
Alors, oui, il y a, parfois des circonstances dans lesquelles un commentaire qui ne paraphrase pas le code, qui n'a aucune visée pédagogique, qui ne débat pas du choix de l'algorithme peut s'avérer intéressant.
- Un commentaire qui paraphrase le code est, au mieux, inutile, au pire carrément dangereux.
- Un commentaire qui justifie l'utilisation d'un algorithme au lieu d'un autre n'a rien à faire dans le corps de la fonction
- Un commentaire à visée didactique n'a, a priori, rien à faire dans un code de production... Laissez le aux profs et aux tutoriels
Mais, avant d'écrire un commentaire, il faudrait peut être se poser la question de ce qu'il apporte réellement de plus que ce que le code ne dit!
Si la réponse n'est "pas grand chose", peut etre que ce pas grand chose pourrait être apporté directement par le code lui-même en utilisant un terme "à peine moins ambigu" non
Si la réponse est carrément "rien", pourquoi rajouter un commentaire qui ne présente aucun intérêt
Il n'y a plus finalement que le cas où le commentaire peut, effectivement, apporter quelque chose qui correspond, finalement, à l'explication du "cheminement intellectuel" suivi par le développeur lorsqu'il a pris une décision qui n'apparait pas au niveau du code.
Mais ce cas, s'il n'est pas inexistant (autrement je n'en aurais pas parlé), est, à tout le moins, exceptionnel
J'ai réécrit 2 applis dans ma vie, et je suis d'accord avec ce principe, mais il faut quand même être méfiant. Et c'étaient 2 batches, je ne suis pas sur que ça soit aussi facile en transactionnel. Et, dans les 2 cas, les conditions étaient particulières.Réécrire une application a ses avantages, mais que si tu prends en compte l'expérience accumulée.../coupé pour cause de longueur/...).
CAS 1 : une horreur inmaintenable change de format de sortie. Le contenu, lui, ne change pas. On me confie la tache de créer une chaine de zéro, qui aie strictement la même sortie en termes fonctionnels(mais au nouveau format).
Ma solution : on déplie lentement le code existant, on essaye de le comprendre, on le rend plus lisible. La seule différence avec la méthode Rub a dub dub, c'est que c'étaient de nouveaux composants.
Ca m'a obligé à tester en comparant à l'existant. J'ai du monter une usine à gaz pour comparer systématiquement toutes les données de l'ancienne chaine, et celles de la nouvelle. Mais, en faisant tourner une année complète de prod sur les deux chaines, on est arrivés à un truc impeccable.
CAS 2 : Une chaine peu fiable change de format de sortie. Mais, au contraire du cas 1, j'ai des specs. Et, en fait, la plupart des "fonctions" sont altérées. Ca ressemble à l'ancien, ça a le gout de l'ancien, mais en fait ça n'a rien à voir. Nous avons cannibalisé de l'ancien les 3 fonctions que nous pouvions laisser inchangées, et avons tout refait. Néanmoins, l'ancien nous a aidé sur bien des plans. Car il tapait sur les mêmes référentiels, et allait chercher des données similaires. Donc, nous avons refait un code, en lisant un existant, comme si c'était un exemple internet.
Mais, dans les deux cas, les commentaires nous ont été d'une aide inestimable. Spécialement dans le premier cas, il y a certains algorithmes dont je n'ai jamais compris le fonctionnement. Je les ai remis au normes, mais c'est tout. Certains avaient des commentaires du genre "Attention, cette taxe d'assurance autombile ne sert que pour les produits A & B". Ca a permis de comprendre le contexte dans lequel tout celà était fait. Et donc de donner sens à du code bien obscur.
J'ai pu remettre en état et faire fonctionner comme l'ancien des horreurs non commentées, mais au final, on ne sait toujours pas à quoi elle servent. Ca peut poser problème pour des maintenances ultérieures. Avoir la prétention de faire du code "propre" qui n'a pas besoin de commentaires, ça me parait dangereux. Même si c'est parfois possible. Je fais tout, personellement, pour avoir un code propre. Et je commente quand même. Des fois que je me fasse des illusions sur ladite propreté.
J'avais prévu une réponse courte juste pour répondre à ce post mais finalement une autre formulation, peut-être plus claire, m'est venue à l'esprit, donc voilà encore un pavé {'^_^}.
Évidemment qu'il faut être méfiant, mais où ? Ce n'est pas le fait de réécrire l'appli qui t'as posé problème, mais plutôt le fait que tu n'arrivais pas à récupérer l'"expérience" utilisée dans la version précédente pour faire correctement la suivante. Si le code est indigérable, il est évident que tu auras des soucis, et les commentaires seront utiles (si clairs et à jour).
Dans le second cas tu as les spec, ce qui est bien, mais en général les spec restent à un certain niveau et ne descendent pas jusqu'au niveau nécessaire pour les traduire directement en code. Il y a donc des choix d'implémentation à faire. Et dans l'ancien code ces choix ont été faits, mais si tu n'as rien pour te dire comment ont été fait ces choix tu risque effectivement de repasser par les même bugs.
Au passage, le commentaire que tu donnes est typiquement le genre de chose que j'imagine avoir dans un algo optimisé, qui vise donc à exploiter les spécificités du système pour être mieux (que ce soit en vitesse, mémoire ou que sais-je). C'est le seul cas où j'admets qu'il soit nécessaire d'avoir des commentaires (tout peut toujours être utile, mais pas nécessaire, la question elle est là).
Maintenant, je reformule un peu ma théorie : une fonction intégralement conçue pour une classe d'utilisations donnée peut toujours être codée de manière claire sans commentaire pour cette classe d'utilisation, ni plus ni moins. Il s'agit de définir puis respecter un algo. Dès lors, tu définis l'algo, et quand il est près (pas avant) tu le code. Ça se limite à de la traduction d'un langage formel à un autre, un simple mapping... si tant est que tu utilises un langage qui te le permet : on code pas en Lisp parce qu'on veut coder en Lisp, mais parce que l'algo est exprimé de manière que ça se traduit bien en Lisp.
Si tu ne respectes pas cette condition, donc soit tu fait une conception à l'arrache (ou juste incomplète) soit tu considères une classe d'utilisations différente, alors oui tu auras besoin de commentaires pour bien faire comprendre que ton code fait ce qu'il est censé faire. Le premier cas, c'est le plus courant : qui fait l'effort nécessaire pour avoir une conception intégrale avant de coder ? Tellement peu de monde. Pourtant ça existe : des algos bien connus, même complexes, on n'a qu'à les récupérer sur le net, sous forme de pseudo code. Il ne reste qu'à corriger les erreurs dus au changement de langage. C'est ce que je fais et ça n'a jamais loupé. Quand j'implémente un algo ça marche généralement du premier coup (je dis généralement pour rester ouvert, mais je ne me rappelle pas de cas qui aient foiré). Et là où je choppe l'algo, il y a généralement des examples parce que c'est du wikipédia ou un tuto sur le sujet, du coup je fais des tests automatisés sur ces exemples, et ça passe généralement vert dès le départ (cela dit j'ai déjà eu du rouge, mais à cause d'une erreur dans l'exemple).
Le second cas (classe d'utilisations différente), soit tu considères des cas hors de la classe d'utilisation de base, donc tu utilises la fonction pour un cas qu'elle n'est pas censée faire, et là oui ça bug et tu dois adapter, et même commenter pour dire que si tu fais pas ça ça marche pas dans ton cas... ce qui est normal mais est du à une erreur de conception, donc même style de cas que précédemment. Sinon tu utilises l'algo dans des cas très spécifiques, donc une classe d'utilisation plus réduite, et tu en profites pour exploiter ce que j'appelle des "subtilités du système" : tu sais des choses en plus que l'algo n'est pas censé savoir, et du coup tu optimises ta fonction sur la base de ces connaissances. C'est le seul cas qui me semble justifié de commenter : ces connaissances étant hors du champs de l'algo, si tu optimises pour les exploiter il te faut les renseigner quelque part pour que le suivant puisse avoir ces même connaissances pour ne pas faire de régression. Le code décrivant le "comment" et non le "pourquoi", tu ne peux pas le décrire via le code et il te faut donc ajouter des commentaires.
Par exemple, si je veux calculer la durée moyenne d'un téléchargement étant donné l'ensemble de paquets reçus dans un laps de temps donné, l'algo est de récupérer le temps min et le temps max en faisant un parcours des paquets et de faire le calcul de moyenne sur le nombre total de paquets. Mais si pour mon système je ne considère que des ensembles ordonnés chronologiquement, je n'ai pas besoin de faire ce parcours, je peux récupérer le premier et le dernier paquet pour avoir le temps min et le temps max. Je remplace donc mon parcours par un "getFirst() + getLast()". L'algo censé être représenté étant toujours le générique, il est important de mettre un commentaire pour indiquer pourquoi on a cette différence dans son implémentation.
Néanmoins, cela n'est vrai que si effectivement tu considères des algos plus génériques que nécessaires à la conception et tente de les optimiser à l'implémentation. J'imagine déjà koala01 répondre que si tu sais que c'est toujours le cas tu peux intégrer ça directement dans ta conception et du coup les commentaires deviennent inutiles. Je suis bien d'accord. Mais pour ceux qui veulent profiter d'une conception déjà faite et robuste (donc on exploite l'expérience passée, on ne la perd pas) on peut tomber sur ce genre de cas. Et pour moi c'est le seul pour lequel il soit nécessaire d'avoir des commentaires malgré que le code soit bien écrit (pour rappel, tous les autres cas mènent à un code mal écrit car ne correspondant pas à la conception, alors qu'ici ça correspond car le contrat est respecté).
Mais encore une fois, je le précise, le but n'est pas de dire "ce code existant est mal écrit donc faut taper sur celui qui l'a fait" mais "si je veux avoir un code bien écrit dès maintenant il y a des astuces que je peux appliquer". Le but n'est pas de justifier ou non le bien fondé d'un code déjà mal (ou bien) écrit. Et encore moins de définir la "bonne écriture" sur une pratique moyenne. Toute remarque visant donc à parler d'un cas particulier qu'il aurait vécu n'a aucun intérêt pour attester de la nécessité des commentaires. L'utilité se définit sur le cas particulier, mais la nécessité sur l'ensemble des cas. Pour les plus matheux, il est suffisant mais pas nécessaire d'avoir des commentaires si on a un code bien écrit.
Je suis très cerrtainement un vieux croûton, mais j'aurais plutôt mis en sens inverse :
Il est nécessaire d'avoir des commentaires, même si on a un code bien écrit, mais ce n'est pas suffisant..
Evidemment, on ne parle d'un algo qui fait a+b=c...
@Matthieu Vergne : je veux voir le code d'une application complète sans aucun commentaire qui soit parfaitement compréhensible rien que grâce au génie du génie (non ce n'est pas une répétition) qui a écrit le code. Le code complet + les docs nécessaires pour le comprendre (il y en a forcément si l'appli fait des choses non triviales). D'ailleurs il me semble qu'on ne peut en fait pas éviter d'ajouter des commentaires dans le code faisant le lien entre la doc extérieure au code et le code lui-même. Dur de mettre toutes les infos utiles pour cela dans le code à propremet parler, même si l'on est un génie, donc un peu de commentaire ne ferait pas de mal, si ?
Les commentaires ne sont pas nécessaires au sens strict du terme, sinon les compilateurs ne pourraient pas se permettre de les ignorer... néanmoins, dès que l'on n'est pas tout seul A VIE sur un projet, il faudrait être sacrément tordu pour ne pas commenter. Bien sûr qu'il faut rendre le code aussi beau et clair possible pour qu'il y ait besoin du moins de commentaires possibles... mais je voudrais vraiment voir un bel exemple avec zéro commentaire, ça, ça m'impressionnerait !
(et encore, même tout seul à vie sur un projet, je crois que je n'arriverais pas à éviter tout commentaire)
ok on est d'accord.C'est pas le principe d'un programme ce que tu décris là ? A moins que tu mettes tout dans une grosse fonction Main() ?
Mais il faut tout de même que ça soit intelligemment construit.
Hors beaucoup de gens ont la manie de faire des copier-coller de code ( ce dont voulait parler CapFlow )
Ce qui est important c'est de factoriser le code
Dis toi que que tu sois seul à vie sur un projet ou non, cela ne changera pas grand chose à la donne!
Il suffit d'avoir du revenir sur du code par toi même écrit il y a six mois ou un an pour savoir qu'il est parfois difficile de s'y retrouver dans son propre code
Mais, contrairement à ce que cette réponse peut laisser penser, ce n'est pas forcément une raison pour commencer à commenter son code : quelque part, lorsque tu éprouves le besoin de commenter ton code, c'est très clairement parce que tu te rends compte que ton code a "quelque chose" qui le rend difficile à comprendre.
Pourquoi appliquer un emplâtre sur une jambe de bois en ajoutant un commentaire au lieu d'apporter une solution beaucoup plus pérenne en rendant directement le code lui-même plus clair
Alors, effectivement, si tu rajoute un "bug #1023 : il y avait ceci qui n'est pas pris en compte", ou un "je sais, VAR n'est pas initialisée, mais ce n'est pas grave parce que...", ce sont effectivement des commentaires qui peuvent se justifier.
Mais, sur tous les commentaires que tu écris, combien font partie de ces deux catégories et combien ne rajoutent rien par rapport à ce que le code exprime (mal à cause d'un mauvais choix de nom) de lui-même
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager