Discussion :

[souviron34]

Ce que l'on me demandera en tant que développeur, c'est d'apporter une solution au fait que la fonction ne fait, justement pas, ce qu'elle est sensée faire, on est bien d'accord

Non, pas vraiment

On te demandera beaucoup plus vraisemblablement d'ajouter une condition, un cas, une "nouvelle" exception, un paramètre, un traitement supplémentaire, une nouvelle fonctionalité se servant de cette fonction, etc...

la question du débat est "un code bien écrit a-t-il besoin de commentaires", la réponse que Matthieu et moi-même donnons est "un code bien écrit devrait se suffire à lui même".
....

Absolument pas: cela veut juste dire que l'on considère que la présence de commentaires est l'un des indices(car il y en a d'autres) qui auraient tendance à faire baisser la qualité d'écriture du code.

Et moi je te dis que c'est le contraire : la présence de commentaires est un indice du fait que c'est un bon code

on dit que c'est très certainement le cas des commentaires qui ne font que paraphraser le code ou qui indiquent une étape intermédiaire au sein de la fonction (sur base de langage qui permettent l'utilisation de fonction / sous routines, évidemment).

Autant nous sommes tous d'accord sur la première partie, mais pas du tout sur la seconde...

Et je vais même aller jusqu'à dire que, plus un code est vieux, plus il a été remanié au fil du temps, plus on peut parfaitement comprendre qu'un code puisse nous paraitre "mal écrit" selon nos critères.
...
Mais le problème ne se situe pas au niveau du code vieux de cinq, dix ou quinze ans, qui a été remanié un nombre incalculable de fois, le problème se situe au niveau du "nouveau" code, celui qui est écrit maintenant: ce n'est pas parce que le "vieux" code respectait (ou non) des règles propres aux "standards de l'époque" qu'il faut obligatoirement continuer à respecter ces règles qui ont très certainement démontré leurs limites au fil du temps si elles ont été adaptées pour être ce qu'elles sont aujourd'hui.

Ce qu'on te dit, c'est que ton code qui respecterait les "standards" d'aujourd'hui ne les respectera pas plus dans 15 ans que le code de 15 ans t'apparait les suivre aujord"hui...

Parce que TON code sera remanié un nombre incalculable de fois, pas des ens différents...

Après, il y a tout le problème du code écrit il y a trente ans qui, dés le départ, ne respectait pas les règles de l'époque (à l'époque, la règle était "maximum 50 lignes par fonctions, par exemple).

Et ???

Même avec 50 lignes tu peux avoir du mal à comprendre la fonction, l'algo, etc.. Et cette règle de 50 lignes n'a été que très très peu appliquée, et uniquement dans certains contextes spécifiques (la NASA par exemple)..

Mais ce code là, même à l'origine, n'aurait très certainement pas été considéré comme "bien écrit" même par quelqu'un qui l'aurait relu, en suivant les règles en cours à l'époque.

Tu te goures... A l'époque, comme aujourd'hui, ce qu'on demande à un code c'est qu'il fonctionne et soit maintenable...

Il est quelquefois beaucoup plus facile à maintenir, pour la logique impliquée, d'avoir une seule fonction de 2000 lignes que 40 fonctions de 50 lignes.. Mais aussi pour des questions de performance, de modifications de paramètres en cours de route, d'évitemenent d'avoir des dizaines de variables globales, etc...

[Mat.M]

Et moi je te dis que c'est le contraire : la présence de commentaires est un indice du fait que c'est un bon code

oui on s'en doute un peu ; ce fil de discussion ça repose totalement sur une véritable lapalissade ( ce qu'on appelle aussi une tautologie ): faut il mettre des commentaires dans du code ?
Une lapalissade c'est une affirmation dont le sens est évident.
Donc l'initiateur de ce fil de discussion ( Hinault Romaric) a fait fort de lancer un sujet susceptible de déclencher des trolls.
Sur plus de 23 pages.
Et certains intervenants de disserter sur plus de cinquante lignes à ce sujet de la même manière qu'on peut disserter sur Platon ou Descartes ( ou sur Marc Dorcel )
C'est comme le sketch des Inconnus "quel est la différe nce entre le bon et le mauvais chasseur"

Il est quelquefois beaucoup plus facile à maintenir, pour la logique impliquée, d'avoir une seule fonction de 2000 lignes que 40 fonctions de 50 lignes.. Mais aussi pour des questions de performance, de modifications de paramètres en cours de route, d'évitemenent d'avoir des dizaines de variables globales, etc...

si tu écris une fonction avec 2000 lignes de code c'est que ton code a été mal structuré quelque part.
A moins que tu ne réecrives des trucs pointus comme la compression/décompression JPEG.
Mais en milieu professionnel j'en doute que tu aies à faire de telles choses c'est plutôt mettre des comboboxes et des listboxes sur une form avec des classes toutes faites,bref du travail destiné à des gens avec bac-1 et réalisés par des gens avec bac+5 ( aïe pas taper )

De toute façon écrire du bon code non seulement c'est une lapalissade mais en plus c'est "dépassé"
Maintenant ce qui compte c'est une bonne architecture logicielle

[souviron34]

si tu écris une fonction avec 2000 lignes de code c'est que ton code a été mal structuré quelque part.
A moins que tu ne réecrives des trucs pointus comme la compression/décompression JPEG.
Mais en milieu professionnel j'en doute que tu aies à faire de telles choses

Et pourtant ....

J'en ai déjà fait au moins 2, en milieu totalement professionnel : des boucles d'affichage infinies, avec au milieu 250 000 trucs qui se modifient aléatoirement au bon vouloir de l'utilisateur, qui modifient les paramètres d'affichage dans la boucle, plus des données qui arrivent en temps réel, qui suivant leurs types vont demander des calculs, qui vont influer sur l'affichage, de la simulation de temps réel, etc etc... avec des pauses, ou des accélérations possibles, etc etc...

J'aurais pu tout découper en paquets de 50 lignes, mais ça m'aurait fait plus de 20 fonctions à plus de 200 paramètres, ou plus de 200 variables globales...

Au choix

Là, c'était cohérent, et il y a avait un ordre et une suite logique, avec des "reprises" des modifications en direct....


Alors, c'est pas du site Web, mais c'est pas vraiment très rare, dans les grosses appls industrielles..


(d'autant plus qu'avant les imprimantes permettaient de lister le code sur un papier continu, sur lequel on pouvoir voir 300 ou 100 lignes d'un coup en l'étalant : les informaticiens se sont tirés dans le pied en trouvant l'imprimante page à page).

Maintenant ce qui compte c'est une bonne architecture logicielle

Et pourquoi "maintenant" ????

C'est ce qui a toujours compté....

[koala01]

Et pourtant ....

J'en ai déjà fait au moins 2, en milieu totalement professionnel : des boucles d'affichage infinies, avec au milieu 250 000 trucs qui se modifient aléatoirement au bon vouloir de l'utilisateur, qui modifient les paramètres d'affichage dans la boucle, plus des données qui arrivent en temps réel, qui suivant leurs types vont demander des calculs, qui vont influer sur l'affichage, de la simulation de temps réel, etc etc... avec des pauses, ou des accélérations possibles, etc etc...

J'aurais pu tout découper en paquets de 50 lignes, mais ça m'aurait fait plus de 20 fonctions à plus de 200 paramètres, ou plus de 200 variables globales...

Au choix

Tu n'aurais pas pu envisager de créer une (ou plusieurs) structure(s) idoine(s) pour y placer les différentes valeurs

Cela ne t'aurait il pas permis de réduire le nombre de paramètres à quelque chose de "raisonnable"

Là, c'était cohérent, et il y a avait un ordre et une suite logique, avec des "reprises" des modifications en direct....


Alors, c'est pas du site Web, mais c'est pas vraiment très rare, dans les grosses appls industrielles..

Deux fois, en quoi? 10, 15... 20 ans de carrière

Je ne dirais pas que c'est rare, je dirais que c'est exceptionnel

Bien sur, il y a une sorte de loi qui dit que, si tu es confronté une fois à quelque chose que tu ne connais pas, tu y seras confronté une deuxième fois très "rapidement" après (je l'ai expérimentée plus d'une fois, et pas forcément dans le domaine du développement)...

Mais si on n'y est confronté que deux fois en plusieurs années d'expérience, même si l'on y est confronté deux fois en moins de quinze jours, cela reste exceptionnel

(d'autant plus qu'avant les imprimantes permettaient de lister le code sur un papier continu, sur lequel on pouvoir voir 300 ou 100 lignes d'un coup en l'étalant : les informaticiens se sont tirés dans le pied en trouvant l'imprimante page à page).

Par contre, sur ce coup, je suis 100% d'accord avec toi

Et pourquoi "maintenant" ????

C'est ce qui a toujours compté....

Et sur ce coup également

[koala01]

Non, pas vraiment

On te demandera beaucoup plus vraisemblablement d'ajouter une condition, un cas, une "nouvelle" exception, un paramètre, un traitement supplémentaire, une nouvelle fonctionalité se servant de cette fonction, etc...

Quoi qu'on puisse me demander, à partir du moment où je suis engagé comme développeur, c'est pour écrire ou modifier du code.

Et si je ne connais pas un minimum le langage dans lequel le code est écrit, tous les commentaires du monde ne pourront pas m'aider (à part pour apprendre le langage, mais ce n'est pas ce que l'on attend d'un code de production )

Et moi je te dis que c'est le contraire : la présence de commentaires est un indice du fait que c'est un bon code

Il est clair que si tu estimes comme normal d'avoir régulièrement des fonctions de plus de 100-150 lignes, c'est un point de vue qui se tient

Personnellement, je commence vraiment à avoir du mal à suivre dés qu'une fonction fait plus de 75 à 100 lignes, parfois plus, parfois moins, cela dépend du contexte.

Du coups, sachant que je n'aime pas les commentaires qui paraphrasent le code, ben, je fais en sorte de garder de "petites fonctions bien spécifiques"

Ce qu'on te dit, c'est que ton code qui respecterait les "standards" d'aujourd'hui ne les respectera pas plus dans 15 ans que le code de 15 ans t'apparait les suivre aujord"hui...

Est-ce que j'ai seulement une seule fois dit que j'estimais que mon code serait considéré comme bien écrit ad vitam

Parce que TON code sera remanié un nombre incalculable de fois, pas des gens différents...

Très certainement

Dans un premier temps, par des gens qui partagent très certainement ma vision d'un code "bien écrit".

Après, si mon code "survit" pendant quinze ans, il y a de fortes chances que mon code actuel ne respecte plus les standards futurs.

Mais si les dieux me le permettent, le code que j'écrirai dans quinze ans essayera de respecter les standards du moment

Et ???

Et ??? Et bien, tout est là, un code qui fonctionne ou un code qui fonctionne rapidement n'est pas forcément synonyme de code "bien écrit".

On peut qualifier un code qui fonctionne de code "correct", de "code optimisé", parfois de "code bien écrit", mais il est plus facile d'avoir un code qui fonctionne au départ d'un code bien écrit qu'un code bien écrit au départ d'un code qui fonctionne

Même avec 50 lignes tu peux avoir du mal à comprendre la fonction, l'algo, etc.. Et cette règle de 50 lignes n'a été que très très peu appliquée, et uniquement dans certains contextes spécifiques (la NASA par exemple)..

C'est en fait parce que cette règle était régulièrement énoncée de manière arbitraire / mal justifiée / mal énoncée, ce qui fait que les gens la comprenaient mal de manière générale.

Du coup, cette règle, je l'admets bien volontiers, causait plus de tord que le bien qu'elle n'apportait, parce que beaucoup de monde essayait de la respecter avant d'essayer de respecter d'autres règles bien plus importantes

Et pourtant, quand elle est comprise pour ce qu'elle est (il faudrait en réalité conseiller de garder "une taille raisonnable" à ses fonctions, quitte à indiquer un nombre de lignes approximatif) et correctement appliquée (comprends : sans essayer de recourir à du code crade pour arriver à la respecter ), cette règle tend quand même à rendre le code beaucoup plus facile à suivre

Tu te goures... A l'époque, comme aujourd'hui, ce qu'on demande à un code c'est qu'il fonctionne et soit maintenable...

Ce qui n'est pas forcément synonyme de code "bien écrit".

Le code qui fonctionne et le code "bien écrit" sont deux choses totalement indépendantes : tu peux avoir un code qui fonctionne mais qui est "mal écrit", un code qui ne fonctionne pas mais qui est "bien écrit" et un code "bien écrit" et qui fonctionne.

Ce sont là deux notions totalement transversales

L'idéal, nous serons d'accord sur ce point , sera d'arriver à un code bien écrit et qui fonctionne

De la même manière, si un code "bien écrit" sera a priori d'office maintenable, ce n'est pas parce que ton code est maintenable qu'il est forcément bien écrit.

Mais bon, le tout est une question de point de vue.

Tu estimes qu'une fonction de 200 lignes et plus peut être bien écrite si elle est parsemée de commentaires, j'estime que le code devrait se suffire à lui-même et que les fonctions de plus de 75 à 100 lignes devraient être redécoupées, afin, justement, d'avoir à rajouter des commentaires que je juge "inutiles".

"Autres temps, autres moeurs"

[souviron34]

Tu n'aurais pas pu envisager de créer une (ou plusieurs) structure(s) idoine(s) pour y placer les différentes valeurs

Cela ne t'aurait il pas permis de réduire le nombre de paramètres à quelque chose de "raisonnable"

J'avais déjà tout un tas de structures... Sauf que presque chacune pouvait etre modifiée, et que toutes elles rentraient dans cette boucle infine...

J'ai tenté au mieux pour la compréhension du code...et pour la maintenance et la cohérence....

Et si je ne connais pas un minimum le langage dans lequel le code est écrit, tous les commentaires du monde ne pourront pas m'aider (à part pour apprendre le langage, mais ce n'est pas ce que l'on attend d'un code de production )

Mais pourquo donc te focalises-tu sur le langage ???

Les commentaires dans le code ne sont pas là pour expliquer l'utilisation du langage..... Mais l'algorithme et le pourquoi de telle ou telle condition ou appel....

Tu estimes qu'une fonction de 200 lignes et plus peut être bien écrite si elle est parsemée de commentaires, j'estime que le code devrait se suffire à lui-même et que les fonctions de plus de 75 à 100 lignes devraient être redécoupées, afin, justement, d'avoir à rajouter des commentaires que je juge "inutiles".

"Autres temps, autres moeurs"

Non, je pense juste tailles des projets...

Depuis 25 ans, je n'ai quasiment jamais travaillé sur un projet de moins de 500 000 lignes....

Dans ces contextes, tu as au minimum 14 ou 15 000 fonctions, et déjà une 60 aine de "modules" de 5000 lignes chacun.... Si tu découpes toutes tes fonctions à un max de 50-75 lignes, tu vas te perdre, que ce soit en nombre de fonctions ou en nombre de fichiers/modules...

Dans ces cas, qui comme je disais sont tous ceux sur lesquels j'ai travaillés depuis plus de 25 ans, l'important est le regroupement par fonctionalité... Les découpages plus fins sont initéressants, et même assz débiles, car ils ralentissent le suivi lors d'un debug, les corrections, les évaluations, etc etc....

Alors bien sûr tu essayes de faire court, mais tu essayes aussi d"aviter les getters/setters, tous les trucs courts qui ne font qu'une seule tâche.... Et tu es très rarement en dessous de 100, voire de 200 ou 300 lignes....

[koala01]

J'avais déjà tout un tas de structures... Sauf que presque chacune pouvait etre modifiée, et que toutes elles rentraient dans cette boucle infine...

J'ai tenté au mieux pour la compréhension du code...et pour la maintenance et la cohérence....

Je posais réellement la question, avec un très grand intérêt pour la réponse.

Tu me dis que c'était réellement impossible, je te crois sur parole... Mais disons que l'on peut estimer comme "dommage" le fait qu'il n'y ai pas eu moyen de le faire, tu ne trouves pas

Mais pourquo donc te focalises-tu sur le langage ???

Les commentaires dans le code ne sont pas là pour expliquer l'utilisation du langage..... Mais l'algorithme et le pourquoi de telle ou telle condition ou appel....

Car, comme je te dis depuis que l'on a abordé le sujet, si le développeur qui lit les commentaires n'est pas en mesure de vérifier que le code fait bel et bien ce que prétendent les commentaires, tout ce qu'il peut faire grâce à eux, c'est dire "oui, en théorie cette fonction fait ceci ou cela".

Comme je t'ai dit, je ne prétend pas connaitre perl et je n'entrave que dalle aux langages fonctionnels.

Places moi devant un programme ou même une fonction la plus simple possible en perl, même si elle est bourrée de commentaires, je ne pourrai pas agir en tant que développeur à qui l'on risque de demander de développer à partir de ce code, c'est aussi simple que ca

Maintenant, mets moi devant un code dont je connais le langage, je ne devrais théoriquement pas avoir besoin des commentaires pour comprendre l'algorithme, ni le pourquoi de telle condition ou appel: les noms des variables utilisées pour tester les conditions, les noms des fonctions appelées devraient, si le code est "bien écrit", se suffire à eux même

Non, je pense juste tailles des projets...

Depuis 25 ans, je n'ai quasiment jamais travaillé sur un projet de moins de 500 000 lignes....

Dans ces contextes, tu as au minimum 14 ou 15 000 fonctions, et déjà une 60 aine de "modules" de 5000 lignes chacun.... Si tu découpes toutes tes fonctions à un max de 50-75 lignes, tu vas te perdre, que ce soit en nombre de fonctions ou en nombre de fichiers/modules...

Pas forcément!

Même en C (car je viens de me souvenir que c'est -- me semble-t'il -- ton langage de prédilection), tu n'est absolument pas obligé d'avoir une seule fonction par fichier, que je sache!

Tu n'es même pas obligé de fournir une déclaration de toutes les fonctions dans un fichier d'en-tête, du moment que le compilateur dispose de cette déclaration lorsqu'il rencontre l'appel correspondant!

Qu'est ce qui t'empêche -- en dehors de cas exceptionnels dans lesquels ce n'est décidément pas possible -- de te rendre compte que tu écris une fonction qui fait clairement cinq ou dix choses différentes dans un ordre particulier et donc de sortir ces cinq ou dix choses dans autant de fonctions qui ne feront plus qu'une chose bien particulière

Pour autant que ce soit raisonnablement faisable (j'exclus donc de mon raisonnement les cas exceptionnels où tu t'es retrouvé devant l'impossibilité de regrouper les différents paramètres en des structures idoines), tu as tout à y gagner!

• Tu gagnes en nombre de blocs intermédiaires, et donc en indentation et donc en défilement horizontal
• Tu gagnes en nombre de lignes et donc en défilement vertical
• Tu gagnes en nombre de variables utilisées (donc en facilité à t'en souvenir)
• Et si tu décides de l'exposer au travers d'un fichier d'en-tête (qu'il expose ou non plusieurs fonction ne pose aucun problème ), tu gagnes même l'opportunité de la tester séparément

Dans ces cas, qui comme je disais sont tous ceux sur lesquels j'ai travaillés depuis plus de 25 ans, l'important est le regroupement par fonctionalité... Les découpages plus fins sont initéressants, et même assz débiles, car ils ralentissent le suivi lors d'un debug, les corrections, les évaluations, etc etc....

Sur ce coup là, je ne suis pas d'accord.

Il faut dire que j'ai "tété à la mamelle" des tests unitaires.

Comme aucun test unitaire n'est jamais supprimé (du moins, tant que la fonctionnalité testée existe), lorsque tu es confronté à un scénario qui pose problème et que tu as pu déterminer "à peu près de quel coté" ca coince, ben, tu écris quelques tests unitaires avec des données reproduisant le scénario.

En ayant découpé tes fonctions de sorte qu'au final, ta "fonction qui fait tout" se résume à l'appel de différentes fonctions qui ne font à chaque fois qu'une seule chose, tu arrives assez facilement à déterminer précisément là ou ça coince et, au final, tu n'a plus que les "quelques lignes" (on se comprends sur le terme: cela en laisse peut être 70 ) de une ou deux fonctions à vérifier

Alors bien sûr tu essayes de faire court, mais tu essayes aussi d"aviter les getters/setters, tous les trucs courts qui ne font qu'une seule tâche.... Et tu es très rarement en dessous de 100, voire de 200 ou 300 lignes....

Je suis très attaché, en tant que C++iste, à la loi de déméter.

J'accepte un getter s'il correspond à un service que je suis effectivement en droit d'attendre de la part de mes classes.

Par contre, je remplace avantageusement les setters par des fonctions membre -- clairement nommées -- qui éviteront à l'utilisateur d'éparpiller une même logique dans son code

Et oui, en travaillant de la sorte, je suis plus souvent en dessous même des 25 lignes de code, j'atteins rarement la cinquantaine de lignes, et je n'atteins les 75 lignes et plus que de manière tout à fait exceptionnelle

[el_slapper]

Tiens, le débat à glissé vers la taille des routines. Perso, je suis à mi-chemin entre Souviron et Koala, là dessus : la bonne taille est celle qui est pertinente fonctionellement.


Notemment quand je codait des scripts de tests automatiques. Nous avions des méthodes qui encapulaient chaque action unitaire de l'utilisateur. Des méthodes assez courtes, en général. Par contre, il pouvait y avoir, 100, 150, 200 actions unitaires par script. Toutes décrites unitairement par les testeurs fonctionnels.

Dans ce cadre, quel est la valeur ajoutée de découper le script en morceau? J'avais donc jusqu'à 200 actions unitaires, dont les appels(et la gestion d'erreur) me prenaient entre 5 et 15 lignes chacun. Soit environ 2000 lignes. Le fait d'avoir une seule profondeur d'appel était un avantage majeur, parcequ'à tout moment, le débugger(je vais faire hurler souviron, mais là, il était impossible de faire sans) permettait de savoir à quelle étape exacte du test on était, sans se taper la remontée à travers plein de sous-routines encapsulées. Du premier coup.

D'un point de vu strict du codage, c'était certainement encapsulable. Mais aurait-ce été pertinent? Si on prend en compte le périmètre d'utilisation(ce genre de script est important quand il plante, pas quand il marche bien, et permet de pointer directement sur le comportement non prévu), clairement, non.

Par contre, les élements unitaires étaient eux-même courts, avec plein de sous-routines, parcequ'elles réutilisaient toujours les mêmes composants. Une taille courte, ici, était pertinente. Mais pas dans les scripts eux-mêmes.

[koala01]

Tiens, le débat à glissé vers la taille des routines. Perso, je suis à mi-chemin entre Souviron et Koala, là dessus : la bonne taille est celle qui est pertinente fonctionellement.


Notemment quand je codait des scripts de tests automatiques. Nous avions des méthodes qui encapulaient chaque action unitaire de l'utilisateur. Des méthodes assez courtes, en général. Par contre, il pouvait y avoir, 100, 150, 200 actions unitaires par script. Toutes décrites unitairement par les testeurs fonctionnels.

Dans ce cadre, quel est la valeur ajoutée de découper le script en morceau? J'avais donc jusqu'à 200 actions unitaires, dont les appels(et la gestion d'erreur) me prenaient entre 5 et 15 lignes chacun. Soit environ 2000 lignes. Le fait d'avoir une seule profondeur d'appel était un avantage majeur, parcequ'à tout moment, le débugger(je vais faire hurler souviron, mais là, il était impossible de faire sans) permettait de savoir à quelle étape exacte du test on était, sans se taper la remontée à travers plein de sous-routines encapsulées. Du premier coup.

D'un point de vu strict du codage, c'était certainement encapsulable. Mais aurait-ce été pertinent? Si on prend en compte le périmètre d'utilisation(ce genre de script est important quand il plante, pas quand il marche bien, et permet de pointer directement sur le comportement non prévu), clairement, non.

Par contre, les élements unitaires étaient eux-même courts, avec plein de sous-routines, parcequ'elles réutilisaient toujours les mêmes composants. Une taille courte, ici, était pertinente. Mais pas dans les scripts eux-mêmes.

Ah, il est clair que, sur un script de tests unitaires, tu vas avoir sans doute plusieurs centaines de lignes qui correspondront à peu près toutes à l'appel de la fonction qui teste une fonctionnalité dans une situation particulière.

Tu auras un étalage beaucoup plus "horizontal" que "vertical" (du point de vue de la profondeur d'appel)

Mais là encore, a priori, si le nom des fonctions de tests est correctement choisi, ben, étant donné que c'est une exécution relativement rectiligne (même si tu commence à gérer dans ton script le fait que chaque fonction peut réussir ou non), les commentaires n'apporteront sans doute pas grand chose si tu peux te permettre de rajouter les appels supplémentaires à la fin du script (ou peu s'en faut).

Evidemment, si tu veux que tes tests soient effectués dans un ordre particulier (module par module, par exemple), là, je peux concevoir que l'on mette un commentaire pour permettre aux gens de savoir où ils doivent rajouter l'appel, mais cela n'aura quand même pas grand chose à voir avec la "compréhensibilité" du code

[Mat.M]

Ne te vexe pas, on dit juste que la qualité du code est relative, pas absolue...
...

avec cette logique alors il n'y a pas d'intérêt de mettre des commentaires dans le code...puisque tu affirmes que la qualité du code est matière à subjectivité.

[Mat.M]

Et pourquoi "maintenant" ????

C'est ce qui a toujours compté....

remarque pertinente à laquelle je vais répondre : pour la très simple raison qu'avant il y a 20ans UML ,les méthodologies n'existaient pas ou presque , que les compilateurs et les outils de développement ne permettaient pas de faire de la programmation objet..c'est tout simple
Donc il y a 20ans on ne pouvait pas construire un projet informatique de manière modulaire et structurée comme on peut le faire maintenant

[jouana]

Attention l'objet peut apporter sont lot de complexité dans un projet.

Ce n'est pas pour rien qu'une grosse partie des systèmes reste en C, tu peux vite te perdre dans tes objets.

Le développement modulaire n'est pas propre à l'objet mais à la capacité d'un développeur à se projeter.
Les petites fonctions avec très peu de lignes afin de centraliser et réutiliser au maximum l'implémentation d'un traitement.

Et les librairies dynamique n'existes pas qu'en objet

[souviron34]

remarque pertinente à laquelle je vais répondre : pour la très simple raison qu'avant il y a 20ans UML ,les méthodologies n'existaient pas ou presque , que les compilateurs et les outils de développement ne permettaient pas de faire de la programmation objet..c'est tout simple
Donc il y a 20ans on ne pouvait pas construire un projet informatique de manière modulaire et structurée comme on peut le faire maintenant

Je te conseillerais de te documenter plus profondément, et de lire les débats, ici-même, sur le sujet...

• Les méthodologies n'existaient pas ?????? Tu rigoles , j'epère.....
• UML n'est qu'un outil, ça ne change rien à la manière
• le C++ date de bien avant que ça, Delphi (avec ObjectPascal) est sorti en 1990. Et C++ est fabriqué gràce à C, et à son compilateur.
• X11 (XWindows), comme après lui Motif, est écrit en C, en objet, et date de .. 1978.. Première version publique 1984. Tu devrais sérieusement regarder le code XFree86 ou de X11.... Tu y verrais de l'objet, de l'encapsulation, de l'héritage, de la surcharge, des événements, des handlers, des exceptions.. et tout ça en C pur....
• La programmation structurée, et la programmation modulaire, n'a strictement rien à voir avec les langages objets. (il y a des programmes Fotran et même asembleur parfaitement modulaires (et heureusement !!))

Révises et renseignes-toi, stp... Excuse-moi, mais là tu fais le parfait ignorant qui se croit supérieur... et ne fais que raconter des âneries... (ici, sur ces derniers posts)

[Matthieu Vergne]

Tu peux au moins lui concéder ça je pense {'^_^} :

Donc il y a 20ans on ne pouvait pas construire un projet informatique de manière modulaire et structurée comme on peut le faire maintenant

Les méthodes et outils (langages inclus) ont évolué, ce qui permet de faire tout ça au moins plus facilement que dans le temps (ou de faire plus complexe avec la même difficulté, ce qui revient au même). Mais c'est sur que tout n'est pas apparu du jour au lendemain parce que certains illuminés ont découvert UML ou que sais-je : quand une théorie tombe, c'est qu'il y a déjà eu des essais et comparaisons (au moins empiriques) faites avant. Quand tu as une théorie, la pratique est déjà là quelque part, elle est juste pas formalisée ni (probablement) partagée.

[souviron34]

Non je ne peux pas lui concéder ça

UML n'impose rien de plus convaincant sur la structuration ou modularité du code que ce qui se faisait avant : ça dépend de l'architecte.

Et je dirais même qua c'est encore pire, car avec des langages objets, souvent on sur-module, on sur-découpe, et je mets ma main à couper que la structuration est pire, dans la majorité des gros projets...


Il est réellement étrange que vous croyiez à ce point vous-mêmes ou vos techniques tellement supérieur(e)s qu'elle rendraient le boulot de tous vos prédeceseurs stupide, mal fagoté, mal structuré, pas pensé, pas conceptualisé...

Eh oooooo ?? Le monde a tourné avant et a fabriqué ce avec quoi vous travaillez aujourd'hui... ça devait être pas si mal pensé ou structuré, hein ??

J'ose espérer que c'est de l'ignorance qui vous pousse à dire ça, plutôt qu'un égo et un mépris pour les générations précédentes...

[jouana]

Ca dépend de l'architecte ^^

[Matthieu Vergne]

UML n'impose rien de plus convaincant sur la structuration ou modularité du code que ce qui se faisait avant : ça dépend de l'architecte.

Mais il le décrit et le formalise. Le but n'est pas de dire que les experts d’antan sont obsolètes, mais que les techniques des experts d'antan sont désormais disponibles y compris aux débutants. Et donc à ce titre on peut dire que les dév d'aujourd'hui ont moins de difficultés car disposent de ces outils, et ont donc besoin de moins d'expérience brute pour parvenir au même niveau. Sinon qu'appelle-t-on le progrès (dans notre domaine tout du moins) ?

Après ce n'est que l'outil, on n'est jamais à l'abri d'une mauvaise utilisation. Connaitre la technique ne veut pas dire la maitriser.

Faut pas non plus dénigrer les avancées scientifiques en info sous prétexte que certains faisaient déjà ça dans le temps : on passe de certaines élites à un plus grand public, c'est ça qui est important ici.

À moins que tu sois du genre à protéger jalousement ton expérience souviron34 ? {^_^}

[souviron34]

les techniques des experts d'antan sont désormais disponibles y compris aux débutants. Et donc à ce titre on peut dire que les dév d'aujourd'hui ont moins de difficultés car disposent de ces outils, et ont donc besoin de moins d'expérience brute pour parvenir au même niveau. Sinon qu'appelle-t-on le progrès (dans notre domaine tout du moins) ?

Certainement pas ça

Un débutant ou un "moyen" ne fera pas un travail équivalent à un expert, même en ayant de meilleurs outils..

Je ne vois pas comment tu (vous) ne pouvez pas vous en rendre compte ??

Tu peux avoir des verrines, des cours de cuisine sur le net, ou à la télé, une super cuisiinière de compétition, ça ne fera pas de toi un Chef étoilé..

De même, tu peux avoir les meilleurs pinceaux ou couleurs ou toiles du monde tu ne seras pas un Picasso, ni même un Delacroix... ou un peintre qui vit de la vente de ses toiles...

Le progrès et les techniques permettent aux BONS de faire le même travail plus vite.. Elles ne permettent pas aux moins bons de faire le boulot des bons..

Faut pas non plus dénigrer les avancées scientifiques en info sous prétexte que certains faisaient déjà ça dans le temps : on passe de certaines élites à un plus grand public, c'est ça qui est important ici.

Voir plus haut..... Vous vous gourez totalement : avoir un tournevis qui te donne le courant et le voltage ne fera pas de toi u électronicien, et encore moins un électronicien de haut vol...

Alors tu pourras te faire ton branchement de 3 lampes, et peut-être une mini table de mixage, mais autre chose, de qualité industrielle, j'en doute très très très très fort....


Vous vous faites des illusions, et dangereuses qui plus est....

En fait, vous avez le syndrôme "Star Ac"... ou musicien dans son garage.. Parce qu'il y a maintenant des consoles Midi, qu'il est facile d'enregistrer son CD, ce n'est pas parce qu'on le fait qu'on est musicien....

[koala01]

Sur ce point, je suis tout à fait d'accord avec souviron34 (je le souligne, car c'est rare dans cette discussion ).

On disposes très certainement de plus de sources, pour ceux qui veulent vraiment évoluer, mais à coté de cela, on dispose également de langages qui font tout pour qu'un type qui ne serait même pas considéré comme "à peine correct" face à d'autres langages puisse avoir l'impression d'être un dieu

J'ai, à titre d'exemple, en mémoire quelque discussions concernant le LSP, de SOLID en général ou de Déméter avec des développeurs java dont on se rend compte qu'ils ont une connaissance plus que correcte de leur langage, mais dont on peut se poser la question de leur qualification en terme de conception et développement

S'il est vrai que, comme dit le proverbe, un bon ouvrier aura de bons outils, le seul fait d'avoir de bons outils ne rend, malheureusement, pas encore un mauvais ouvrier meilleur

[Matthieu Vergne]

Mais arrêtez enfin, là c'est vous qui êtes extrêmes ! Je suis pas en train de dire qu'un parfait abruti peut devenir un expert sur le simple fait d'apprendre ce qu'est un diagramme de classe !

Admettez au moins que le fait d'apprendre UML ou tout autre langage de modélisation te donne plus de chances de mieux structurer tes concepts plutôt que d'y aller au feeling ! Au même titre qu'apprendre 1 technique inspirée d'anciens experts est mieux qu'en chercher une par soi-même depuis 0. Parce qu'au moins tu as une base à utiliser pour te faire penser à certains points importants.

Vous prônez la réinvention de la roue en toute circonstance là !