La notion de code source autodescriptif relèverait d’un mythe

La notion de code source autodescriptif relèverait d’un mythe
Entretenu par les programmeurs qui n’ont pas saisi la portée de « documenter »

En programmation, l’écriture de code autodescriptif est une pratique qui implique le respect de certaines conventions de nommage et de programmation structurée. Eric Holscher affirme qu’il y a un amalgame au sein de la communauté des programmeurs en ce qui concerne cette pratique. Ce mélange a – de son point de vue – un impact négatif sur l’utilisabilité des logiciels et applications mis à disposition des personnes sans compétences en programmation.

Eric Holscher – cofondateur de ReadTheDocs, un service en ligne qui héberge de la documentation pour l’industrie du logiciel – entame son propos par une explication de la notion de commentaires. De son point de vue, ces derniers sont un sous-ensemble de la documentation qui devrait accompagner toute œuvre du génie logiciel.

Il va plus loin en ajoutant que ce sous-ensemble particulier est destiné à « documenter le pourquoi et non le comment », c’est-à-dire à : expliquer de précédentes approches qui n’ont pas fonctionné, faire apparaître de possibles améliorations, expliquer les compromis dans l’implémentation en cours, etc.

Ce sous-ensemble est à mettre en cohabitation avec les conventions de nommage et de programmation structurée au sein du code. Ces dernières viendraient ainsi jouer leur rôle qui est – selon lui – de « documenter le comment et non le pourquoi ».

Il semblerait cependant que certains programmeurs fassent fi de ce jeu de rôle et se limitent uniquement au respect des conventions de nommage et de programmation structurée pour affirmer que leur code source est « autodescriptif ». « Je n’ai plus besoin d’expliquer quoi que ce soit puisqu’il est désormais évident que le fonctionnement du programme est accessible à tous », leur attribue-t-il alors.

« Décider que les noms de variables [la convention de nommage] constituent la seule documentation requise signifie que seules les personnes qui lisent le code source peuvent en faire usage », déclare Eric Holscher pour s’indigner du fait que la documentation s’adresse en principe aux « utilisateurs de tous bords ».

Eric Holscher met ainsi de l’emphase sur le fait que la documentation du code va bien au-delà de la mise en œuvre du tandem de règles précédemment mentionné. Se limiter à respecter ces règles conduirait fatalement à exclure les personnes sans compétences en programmation de la liste des potentiels utilisateurs.

Il y a donc plus à faire que mettre côte à côte la « documentation du pourquoi et non du comment » et celle du « comment et non du pourquoi ». Il faudrait en plus penser à l’intégration d’éléments comme les tutoriels susceptibles de booster l’utilisabilité du logiciel ou de l’application déployée.

« Si vous tenez à avoir des utilisateurs pour les œuvres que vous produisez, il va falloir rédiger de la documentation », a-t-il conclu.

Source : blog

Et vous ?

:fleche: Qu’en pensez-vous ?
:fleche: Vous arrive-t-il de ne faire usage que des conventions de nommage au détriment des commentaires ?
:fleche: Partagez-vous l’avis de l’auteur sur la portée qu’il attribue à la notion de documentation en génie logiciel ?

Voir aussi :

:fleche: Programmation : quand faut-il commenter son code ? Google s'invite dans le débat et montre que les commentaires peuvent très souvent être évités
:fleche: Débat qualité développement : Faut-il commenter son code source pour le rendre plus lisible et plus facile à maintenir ? Si oui comment ?

Ce mec ne confond t'il pas la Documentation utilisateur et la documentation Technique ?
Le nom des variable si il doit être commenté c'est en doc technique pour une utilisation en tant que Lib ou pour les futurs mainteneurs du programme, pas pour une utilisation tout public.
Pour les programme de ma boite on tire au sort(3 programmeurs, le choix est rapide) qui vas faire la doc de nos programmes(pas pour les programmes de commande, le cahier des charges fait office de DOC et à chaque modifications le client doit le mettre à jour)

Citation:

---

Envoyé par Patrick Ruiz

En programmation, l’écriture de code autodescriptif est une pratique qui implique le respect de certaines conventions de nommage et de programmation structurée. Eric Holscher affirme qu’il y a un amalgame au sein de la communauté des programmeurs en ce qui concerne cette pratique. Ce mélange a – de son point de vue – un impact négatif sur l’utilisabilité des logiciels et applications mis à disposition des personnes sans compétences en programmation.

---

Pour les logiciels et applications, l'utilisateur n'a rien a faire du code source et de ses commentaires. Pour une lib, le problème commence a survenir, mais il y a deux choses à distinguer : l'interface utilisateur, i.e. ce à quoi la lib donne accès et l'implem. Là, l'utilisateur n'a rien à faire de l'implem, qui est potentiellement privée. La documentation de type doxygen est peut -être utile, mais je préfère un petit tuto/exemple de base et des noms de fonctions explicites qui me permettent de ne pas consulter la doc, sauf dans des cas très particuliers. Documenter l'opération addition sur des entiers, ça n'a pas d'intérêt, documenter les opérations matricielles pour une lib de math, ça n'a pas d'intérêt, par contre documenter la différence entre deux manières différentes de construire une matrice peut être intéressant quand l'une est beaucoup plus rapide que l'autre.

cofondateur de ReadTheDocs, un service en ligne qui héberge de la documentation pour l’industrie du logiciel : il me semble que tout est dit sur la raison de ces propos.

Je lui conseillerait de lire l'excellent Coder proprement.

J'etais jeune et je croyais aussi que le code commente ou la documentation ne servait a rien.

Je vais entendre dans ce post, les trucs classqiues :

• Pas le temps de commente le code ou faire de la documentation
• Pas besoin de commenter, le code est lisible
• Il faut poser plus de questions

Enfin bon je vais evaluer ces trois points que j'entends souvent. Je pense qu'il y en a plus mais c'est les plus frequent.
Quand j'ai rejoint une companie super structure, j'ai decouvert ce qu'on peut etre le dilema pyramidale qu'on pouvait retrouvez chez big-blue ou dans les entreprises japonnaises.

Pas le temps de commente le code ou faire de la documentation
Je voudrais quand j'etais nouveau dans l'entreprise, j'ai aussi eu le cas, "Regarde la documentation (plutot : demerdes toi ...), je suis occupe pour le moment". Ironique non ...
Heuresement, pour moi ils avaient fait de la documentation :ptdr: . Et cette grace a cette doc que j'ai pu avance a mon travail, en posant les question sur le detail qui ets manquant et crucial sur un projet.
Dans le travail, je considere deux methodes car chaque personne a differente personnalite, culture, formation et curiosite.
Vous avez ceux qui cherchent et ceux qui cherchent pas, ceux qui osent poser des questions et ceux qui le font pas. Combien de fois j'ai entendu, oh regarde le jeune il pose beaucoup de questions ... Par contre dans le monde anglosaxons, Oh putains ils posent pas de question du tout.

La documentation est neccessaire peu importe le gens avec qui vous travailles, pour laisser des traces (procedure judiciaire, support techniques car vous travaillez pas tout seul, aide pour le stagiaire pour son rapport, echange ou vente de competence), pour comprendre un mecanisme. A chaque fois, j'entends toujours les memes dire, que le cas particuliers ne viendra jamais.

Par exemple, prenez un gars qui comme moi n'a pas d'experiences mais qui apprend super vite en observant et lisant les documentations pour rendre le produit sien. Certaines boites qui ont tendances a ne pas faire de docs auront tendances a vouloir recruter des seniors, des gens de prepas ou des gens avec 5 ans d'experiences, en gros le mouton a 5 pattes. Pourquoi, tout simplement parce qu'ils veulent pas formes. Dans cas la, je peux comprendre, mais on ferme des portes a gens qui peuvent etonner si on prend les mesures neccessaire pour le partage de connaissance. J'ai vu a sa Londres, et soi-disant ils ont "des penuries" (what a joke).

La documentation a des vertus plus pointus qu'on ne le pense quand on maitrise l'art du business et du management. Et personnellement, je pense qu'un developpeur qui fait que DE coder ne peut pas comprendre ces aspects car il a tres peu de chance de l'avoir appris.


Pas besoin de commenter, le code est lisible
Comme certain l'a expliquer, le but de dire Why ? C'est simplement d'expliquer le mecanisme. Prenons le cas d'une fontion :

Code:

---

afficher();

---

Ok le but c'est de comprendre ce qu'il fait, ce qu'il returne.
Pour l'instant, on peut le dire comme sa :

Code:

---

void afficher(stream output, stream content);

---

Bon c'est un peu mieux, on peut comprendre comment ce a besoin, ce qu'il ressort. Ok c'est cool sur un logiciel, un site-web, une application mobile, le classic quoi ...


Je n'ai pas plus le livre "Clean Code" ou encore "Refactorisation" (trop cher et trop gros :p). J'ai lu par contre celui la : "Practical Object Oriented Design in Ruby". Dans dix ans ou moi je suis parti a la retraite deja, je vais mettre mon application en VR (virtual reality). Sauf que le mechanisme interne que j'ai cree n'est pas du tout pour ce cas. Comment mon remplacent va devoir regler le probleme. Le meme probleme qui se pose quand un de vos services (operateur telephonique, service apres-vente, ...) fait pas bien son boulot, vous devriez pas faire pareil. Dite-vous que cela peut etre vous qui aller continuer ce projet, alors fiates les proprement.


Il faut poser plus de questions
Je ne sais pas quoi dire, a part que "officiellement", toutes questions ne sont pas idiotes. En realite ..., toutes les questions font **** tout le monde. Culture d'entreprise, culture francaise, culture de gars en costard, culture du "camra cafe". Je m'avancerais pas a point. Je ne suis pas magicien.

En somme :
La documentation est super importante, vous cherchez juste des excuse pour ne pas la faire. Mais toutes les vertus sont la. Le context pour le faire differt mais c'est une question de management. Et je pense que faire le radin ne resoudra rien sur le long terme.

Citation:

---

Envoyé par Patrick Ruiz

Se limiter à respecter ces règles conduirait fatalement à exclure les personnes sans compétences en programmation de la liste des potentiels utilisateurs.

---

Heu, il y a une limite quand même…*Ce n'est pas le job du développeur et du code d'enseigner la programmation… Il est quand même attendu de celui qui met la main dans le code ou qui utilise ce code qu'il ai une compétence en programmation. D'ailleurs, Eric Holscher ne parle pas de personnes sans compétence en programmation mais des développeurs qui ne sont pas les développeurs du code en question…

Citation:

---

:fleche: Partagez-vous l’avis de l’auteur sur la portée qu’il attribue à la notion de documentation en génie logiciel

---

La documentation au sens large reste indispensable, que ce soit la documentation des fonctions/classes/modules que les commentaires. Anecdote personnelle : un "architecte" qui me pond une méthode et me dit "tu verra dans la signature comment elle s'utilise"… Ben non patate, ta collection en second paramètre, on sait que de temps en temps elle n'a rien, on peut lui passer un Null ? Idem en retour, quand il n'y a rien, c'est une collection vide ou Null (oui je parle de ce langage NullPointerExceptionGenerator ;) )…

Le problème de cette mouvance résulte surtout des pseudo-agilistes qui ont omis dans "Des logiciels opérationnels plus qu’une documentation exhaustive" le mot "exhaustif" et qui retiennent "pas de documentation"…

Citation:

---

Envoyé par TiranusKBX

Ce mec ne confond t'il pas la Documentation utilisateur et la documentation Technique ?

---

Quand on regarde la source, non, c'est le relais sur Developpez qui est mal rapporté.

Citation:

---

Envoyé par der§en

cofondateur de ReadTheDocs, un service en ligne qui héberge de la documentation pour l’industrie du logiciel : il me semble que tout est dit sur la raison de ces propos.

Je lui conseillerait de lire l'excellent Coder proprement.

---

Tu ne connait pas ReadTheDocs toi…

Citation:

---

Envoyé par martopioche

Le problème de cette mouvance résulte surtout des pseudo-agilistes qui ont omis dans "Des logiciels opérationnels plus qu’une documentation exhaustive" le mot "exhaustif" et qui retiennent "pas de documentation"…

---

Il me semble que les tests unitaires peuvent faire office de documentation :whistle:

La bonne question est de ce poser c'est quoi un code source , un programme informatique, c'est quoi la différence entre le langage naturel et le langage de programmation.
Quand on a passer comme moi plus de 25 ans à coder, j'ai trouvé le code source est juste la représentation formel sans ambiguïté et déterministe du langage naturel.
Donc la question est simple pourquoi donc documenter/commenter un programme et ben il y a aucune raison pour le faire.
Mais en réfléchissant plus la seul et unique raison après pour commenter/documenter un programme est de prendre conscience que le développeur qui reprendra le code sera peut-être un boulet avec peut de capacité de compréhension limité.
Donc pour tous les développeurs amateurs ,incompétent et limité il faut forcement documenter/commenter son code.

Citation:

---

Envoyé par martopioche

Anecdote personnelle : un "architecte" qui me pond une méthode et me dit "tu verra dans la signature comment elle s'utilise"… Ben non patate, ta collection en second paramètre, on sait que de temps en temps elle n'a rien, on peut lui passer un Null ? Idem en retour, quand il n'y a rien, c'est une collection vide ou Null (oui je parle de ce langage NullPointerExceptionGenerator ;) )…

---

Dans un langage comme le Java ou le C qui contient le type "référence qui peut être nulle" sans contenir le type "référence forcément non nulle", en pratique, la plupart des fonctions qui retournent des références retournent des références jamais nulles et la plupart des appels des fonctions sont pensés comme si les arguments n'étaient jamais nuls.
Du coup, à mon avis, avec un tel langage, le mieux est d'adopter une convention qui stipule que toutes les références sont non nulles par défaut. Si une fonction peut retourner une référence qui peut être nulle, il faut alors le signaler explicitement, par exemple avec un suffixe "_canBeNull". C'est moins dangereux que d'espérer que l'utilisateur de la fonction va vérifier dans la documentation si la fonction fait partie des rares fonctions à retourner une référence qui peut être nulle. On peut aussi utiliser le suffixe "_canBeNull" dans des noms de paramètre.

A part ça, dans Java, comme l'absence de type "référence forcément non nulle" est une source d'erreurs, il existe des annotations @Nullable et @NotNull. Mais il existe plusieurs implémentations de ces annotations, aucune n'étant l'implémentation standard.
Plus d'infos ici : https://stackoverflow.com/questions/...n-should-i-use.

En C++, par contre, on a la chance d'avoir la distinction entre pointeurs et références. Les pointeurs peuvent être nuls, pas les références.

Bonjour tout le monde

En lisant le sujet, c'est exactement ce que je me suis dit : la personne mélange les différents niveaux de documentation.

De plus, quand on est sur la documentation grâce aux commentaires de code, pour moi, il ne s'agit pas de documentation. Il s'agit de complément d'information pour des personnes qui relisent notre code.

Mais pourquoi commenter ? Un commentaire n'est pas en soi important.
Pourquoi ne pas créer des méthodes avec des noms clairs ? Pourquoi ne pas créer des classes avec des noms compréhensifs ?

En fait coder, ça peut s'apparenter à créer un nouveau langage : si tu n'as pas le traducteur, il faut aider les autres personnes pour lire ce que tu as écris.

En revenant sur la documentation technique, elle apporte un vrai plus, même si selon moi, c'est une erreur de faire tout le travail à la main. Il existe assez d'outils pour auto-générer une bonne partie de la documentation technique.

La documentation fonctionnelle, si elle est bien organisée, en lien avec la documentation technique et le code (norme organisationnelle) va permettre à tout le monde de comprendre ce que l'on fait dans le code.

A plus
Evan

Citation:

---

Envoyé par Patrick Ruiz

Ce sous-ensemble est à mettre en cohabitation avec les conventions de nommage et de programmation structurée au sein du code. Ces dernières viendraient ainsi jouer leur rôle qui est – selon lui – de « documenter le comment et non le pourquoi ».
[...]
:fleche: Partagez-vous l’avis de l’auteur sur la portée qu’il attribue à la notion de documentation en génie logiciel ?

---

Presque tout a fait d'accord. Surtout quand il s'agit d'une "partie" de code à "intégré" dans un projet (ré-utilisabilité, "le comment"). Se code étant lui même un projet complet ayant sa propre documentation et interface de tests/validations ("le pourquoi").

Bien sur "le comment" d'un algorithme (ponctuel dans une méthode), n'est pas "le comment" d'un "projet". Et encore moins justifier "un pourquoi" (la raison de) ...

Citation:

---

Envoyé par foetus

Il me semble que les tests unitaires peuvent faire office de documentation :whistle:

---

Les tests unitaires sont de la documentation, ils montrent des exemples d'usage des méthodes/fonctions… Mais lorsque tu utilise une lib, tu ne va pas aller te bouffer les tests unitaires pour savoir quelle borne est acceptée dans tes paramètres…

Sérieux, si utiliser une fonction nécessite plus de temps qu'écrire le traitement nécessaire, tu préfère quoi ?

Citation:

---

Envoyé par Pyramidev

Dans un langage comme le Java ou le C qui contient le type "référence qui peut être nulle" sans contenir le type "référence forcément non nulle", en pratique, la plupart des fonctions qui retournent des références retournent des références jamais nulles et la plupart des appels des fonctions sont pensés comme si les arguments n'étaient jamais nuls.
Du coup, à mon avis, avec un tel langage, le mieux est d'adopter une convention […]

---

Merci mais c'est se focaliser sur un cas particulier et simpliste. Pour ce cas, j'ai simplifié à ce que tout le monde comprends sans considérer le métier (et pour être honnête, ce cas a plus de 10 ans, je ne me souviens plus des détails). Il me semble que tu est intervenu sur le sujet commentaire du code, je reprends l'exemple d'un discutable

Code:

---

setAgeCapitaine(int age)

---

où la proposition était d'utiliser un type signé pour éviter un âge négatif…*Mais l'âge d'un capitaine n'est pas juste positif et négatif…

Après, les conventions ont le défaut d'être des conventions et d'être suivies…*ou pas. Lorsqu'elles sont bien implantées (cas de Python par exemple), ça marche. Mais une convention en vigueur dans une boite, c'est en soi beaucoup plus risqué.

Citation:

---

Si une fonction peut retourner une référence qui peut être nulle, il faut alors le signaler explicitement, par exemple avec un suffixe "_canBeNull". C'est moins dangereux que d'espérer que l'utilisateur de la fonction va vérifier dans la documentation si la fonction fait partie des rares fonctions à retourner une référence qui peut être nulle. On peut aussi utiliser le suffixe "_canBeNull" dans des noms de paramètre.

---

Ce genre de suffixe/préfixe, clairement, non… Les noms de fonctions/variables doivent exprimer ce qu'elles font, pas comment et surtout pas représenter une implémentation technique.

Code:

---

getStrudents_canBeNull()

---

est une aberration de lecture, mais surtout, est une fonction qui a fini par être exposée par la lib (ce n'était pas prévu à l'origine) et l'implémentation a changée, elle ne peut plus être Null… On fait quoi ? On garde un nom qui ne veut rien dire ou on change en informant les 8000 établissements de France qu'ils doivent modifier leurs outils qui utilisent notre lib ?

Citation:

---

Envoyé par evanboissonnot

En lisant le sujet, c'est exactement ce que je me suis dit : la personne mélange les différents niveaux de documentation.

---

En fait pas du tout, elle fait exactement la distinction entre les différents niveaux : nommage, commentaires, documentation type JavaDoc, PyDoc, DocBocks…, tutos… C'est bien écris dans son post mais très mal rapporté…

Citation:

---

Envoyé par TiranusKBX

Ce mec ne confond t'il pas la Documentation utilisateur et la documentation Technique ?

---

Avec une doc utilisateur qui explique pourquoi sans dire comment et l'autre qui dit comment sans dire pourquoi, il te reste à jongler avec les deux plus le code pour t'y retrouver...

Citation:

---

Envoyé par martopioche

Merci mais c'est se focaliser sur un cas particulier et simpliste. Pour ce cas, j'ai simplifié à ce que tout le monde comprends sans considérer le métier (et pour être honnête, ce cas a plus de 10 ans, je ne me souviens plus des détails). Il me semble que tu est intervenu sur le sujet commentaire du code, je reprends l'exemple d'un discutable

Code:

---

setAgeCapitaine(int age)

---

où la proposition était d'utiliser un type signé pour éviter un âge négatif…*Mais l'âge d'un capitaine n'est pas juste positif et négatif…

---

Les puristes te diront qu'il faudrait implémenter une classe age. Ainsi on peut utiliser une panoplie de constructeurs. Ok, ça ne fait que déplacer le problème de l'âge négatif au constructeur Age(int yearsFromBirth); mais là on a un nom bien explicite (et on peut même interpréter un âge négatif comme le temps restant avant de naitre). Mais si l'on revient au problème initial, on peut affirmer, que si le code accepte un âge négatif si on ne le veut pas, c'est un bug, pas un manque de documentation.

Citation:

---

Envoyé par raphchar

... si le code accepte un âge négatif si on ne le veut pas, c'est un bug, pas un manque de documentation.

---

Il n'y a pas très longtemps, les organismes financiers du monde entier ont du faire réécrire leurs logiciels pour prendre en compte les taux d'intérêts négatifs.

Citation:

---

Envoyé par martopioche

[...]Mais lorsque tu utilise une lib, tu ne va pas aller te bouffer les tests unitaires pour savoir quelle borne est acceptée dans tes paramètres…[...]

---

C'est vrai, le type de variable doit être commenté, surtout si cette "variable" est une "class" (instance).

Citation:

---

Envoyé par Nebulix

Citation:

---

Envoyé par TiranusKBX

Ce mec ne confond t'il pas la Documentation utilisateur et la documentation Technique ?

---

Avec une doc utilisateur qui explique pourquoi sans dire comment et l'autre qui dit comment sans dire pourquoi, il te reste à jongler avec les deux plus le code pour t'y retrouver...

---

Rien à voir!
La documentation utilisateur c'est: comment utiliser le machin(ça rien à voir avec le code, c'est ne niveau 0 de description d'un programme)
La documentation technique c'est: comment ça fonctionne et structuré

Pour moi ce n'est pas le code lui-même qui doit être commenté, celui-ci doit effectivement être lisible, ou alors pour donner une indication ponctuelle.
(du style //j'ai utilisé la bibliothèque X par facilité, mais la Y serait plus adaptée pour telles raisons)

MAIS : Un programme doit OBLIGATOIREMENT disposer d'une documentation de son API interne !
Sans ça pour moi, c'est comme si on nous filait Java sans sa doc... Et on devrait deviner comment il fonctionne ... Quelle perte de temps

Et là on se rends compte : Tiens il y a deux méthodes servant à faire le calcul de l'optimisation du temps de transport ... Tiens elles ne font pas les même calculs ... Tiens on l'aurait jamais vu sans une documentation de l'API ... Chacun tapant dans l'une ou dans l'autre grâce à une formidable et désespérée transmission orale.

Perso, je ne suis tombé que dans des boîtes qui "n'avait pas le temps" de rédiger cette documentation. Et je leur en veux terriblement.
Maintenant, soit c'est moi qui crée le logiciel (ça va paraître prétentieux) et je sais qu'elle est bien montée/documentée, soit je fais autre chose (chef de projet, management ...)

mais en aucun cas je pourrais re-bosser pour une boîte qui me dit très orgueilleusement : Pas besoin de doc, de toutes façon ça bouge trop vite, on peut pas la maintenir, et tu peux lire le code !
J’appelle ça
1/ de l'ignorance des bonnes pratiques
2/ De l'irrespect total envers les nouveaux venus
3/ Du suicide à long terme

Oui je suis remonté contre 80% des boîtes de devs Française, qui font de l'amateurisme à ce niveau.

Citation:

---

Envoyé par raphchar

Les puristes te diront qu'il faudrait implémenter une classe age.

---

Puriste de quoi ? Parce que les puristes de la POO me diront surtout que si l'objet capitaine a une notion d'âge, celle-ci est définie dans le constructeur puisqu'un capitaine sans âge n'a pas de sens, donc il n'y a pas de méthode setAge.…

Après, celui qui me propose une conception sur ces 3 lignes de commentaire pour me pondre un modèle qui vient complexifier l'ensemble sans apporter de solution, merci, je m'en passe. Car nous sommes d'accord que une classe Age est plus adaptée, mais il faut qu'elle puisse fournir l'âge par une AgeFactory elle même implémentant une AbstractAgeFactory pour prendre en compte les différents types de définition de l'âge. Ainsi, on peut l'injecter dans les CaptainFactory… :cfou:

Sérieux…*tu propose une classe qui encapsule un entier qui n'apporte aucun contrôle métier pour ce cas là… Oué…

Citation:

---

Envoyé par MikeRowSoft

C'est vrai, le type de variable doit être commenté, surtout si cette "variable" est une "class" (instance).

---

Pourquoi "surtout" si c'est une classe ? N'importe quelle donnée, non ?

Citation:

---

Envoyé par martopioche

Anecdote personnelle : un "architecte" qui me pond une méthode et me dit "tu verra dans la signature comment elle s'utilise"… Ben non

---

Citation:

---

Envoyé par martopioche

je reprends l'exemple d'un discutable

Code:

---

setAgeCapitaine(int age)

---

où la proposition était d'utiliser un type signé pour éviter un âge négatif…*Mais l'âge d'un capitaine n'est pas juste positif et négatif…

---

Du coup, pour que les autres lecteurs comprennent, je cite ce que tu avais écrit :

Citation:

---

Envoyé par martopioche

les types non signés n'existent pas dans tous les langages, mais de toutes manières, ils ne borneront que la valeur minimum. Un capitaine de 800 ans a-t-il un sens en supposant qu'il ne peut être un Jedi ? Un capitaine de 5 ans ?

---

Sur cet exemple, je suis d'accord. S'il y a une précondition qui impose que l'âge soit supérieur à 5 et inférieure à 800, ce n'est pas dans la signature de la fonction setAgeCapitaine qu'on le verra.
Après, comme tu l'as dit, l'existence d'une telle fonction serait douteuse, mais c'est un autre sujet.

Citation:

---

Envoyé par martopioche

Ce genre de suffixe/préfixe, clairement, non… Les noms de fonctions/variables doivent exprimer ce qu'elles font, pas comment et surtout pas représenter une implémentation technique.

Code:

---

getStrudents_canBeNull()

---

est une aberration de lecture, mais surtout, est une fonction qui a fini par être exposée par la lib (ce n'était pas prévu à l'origine) et l'implémentation a changée, elle ne peut plus être Null… On fait quoi ? On garde un nom qui ne veut rien dire ou on change en informant les 8000 établissements de France qu'ils doivent modifier leurs outils qui utilisent notre lib ?

---

Dans ce cas, on crée une nouvelle fonction getStrudents et on met l'ancienne fonction getStrudents_canBeNull en dépréciée.
Dans les 8000 établissements de France, ceux qui n'ont pas le temps de maintenir leur vieux code le laissent tel quel et masquent les avertissements de type "dépréciation" s'ils ne l'on pas déjà fait. Ceux qui ont le temps simplifient leur vieux code en changeant progressivement des appels de getStrudents_canBeNull par des appels de getStrudents en supprimant au passage des tests obsolètes de non nullités de référence.

Citation:

---

Envoyé par martopioche

Pourquoi "surtout" si c'est une classe ? N'importe quelle donnée, non ?

---

ok, je rajoute les requêtes SQL. :)

J'ai eu l'occasion d'étudier le problème de modélisation pour BDD vers modélisation pour POO et vis versa... Et vraisemblablement le besoin d'une class age est très caractéristique pour ne plus avoir besoin d'une "zone texte" en implémentant avec certaines libraires. C'est un peu le besoin d'introduire des règles précises à l'information et a sa manipulation, voir même l'affichage ou autres puisque c'est le "contener" de l'information qui décrit le tous. Et comme d'habitude elle est stocker dans un fichier ou BDD ou "puce", c'est donc là que se trouvera les contraintes d'intégration vers l'ihm.

Citation:

---

Envoyé par martopioche

Puriste de quoi ? Parce que les puristes de la POO me diront surtout que si l'objet capitaine a une notion d'âge, celle-ci est définie dans le constructeur puisqu'un capitaine sans âge n'a pas de sens, donc il n'y a pas de méthode setAge.…

Après, celui qui me propose une conception sur ces 3 lignes de commentaire pour me pondre un modèle qui vient complexifier l'ensemble sans apporter de solution, merci, je m'en passe. Car nous sommes d'accord que une classe Age est plus adaptée, mais il faut qu'elle puisse fournir l'âge par une AgeFactory elle même implémentant une AbstractAgeFactory pour prendre en compte les différents types de définition de l'âge. Ainsi, on peut l'injecter dans les CaptainFactory… :cfou:

Sérieux…*tu propose une classe qui encapsule un entier qui n'apporte aucun contrôle métier pour ce cas là… Oué…

---

L'age changeant chaque année, la fonction setAge est nécessaire, j'ai repris l'exemple fournit, sinon il serait plus pertinant d'indiquer la date de naissance. D'ailleurs la classe age peut justement contenir la date de naissance et un pointeur vers la vrai date pour donner l'age véritable. Si on se dit que finalement on va faire comme ça, mais qu'avant on avait des int, il faudra parcourir tout le code à la traque aux âges, sinon, on modifie la classe et voilà! Si l'on modifie le constructeur, c'est simple le compilateur indiquera directement là où il faut faire les modifs.
Après on reste sur un exemple, je ne prétent pas qu'il faille absoluement faire cela. Mais, je suis sûr que certains penserons que c'est une bonne habitude de programmation. D'ailleurs je suis tout à fait certain que tu seras content d'avoir une classe Taille, plutôt qu'un pair d'entier, une classe vec3 ou Vector3d plutôt qu'un tableau de taille 3, sans pour autant ironiser sur le fait d'avoir besoin de Factory.

renseigner donc la date de naissance et une fonction vous retourneras l'age en fonction de la date du jour

Citation:

---

Envoyé par Nebulix

Il n'y a pas très longtemps, les organismes financiers du monde entier ont du faire réécrire leurs logiciels pour prendre en compte les taux d'intérêts négatifs.

---

Oh mon dieu, les pauvres ! On peut envoyer des dons quelque part pour les soutenir dans cette dure épreuve ?

Citation:

---

Envoyé par TiranusKBX

renseigner donc la date de naissance et une fonction vous retourneras l'age en fonction de la date du jour

---

Je dirais même que " l'unité de mesure " n'est pas toujours obligataire, en tous cas, jj/mm/aaaa ou autre, vos mieux pas se tromper...
Le résultat d'un select ne donne pas toujours une seule liste de class déjà bien rempli et compatible (text2int ?)...

Dans mon cas, et dans la généralité des unités de mesures, l'unité de mesure fait toujours partie de l'informations même si elle doit être traduite dans divers langues.

P.S. : Si tu connais les règles d'accès concurrent à la même information, par deux utilisateurs dont un en modification et le signalement de cela (fond de la zone texte qui change de couleur par exemple), tu as déjà aussi compris les raisons d'un tel besoin.

Citation:

---

Envoyé par SimonDecoline

Oh mon dieu, les pauvres ! On peut envoyer des dons quelque part pour les soutenir dans cette dure épreuve ?

---

Connais-tu le projet Louvois. Sais-tu les impacts sur les utilisateurs et le monde en general quand ce genre d'anerie arrive ? Tu te rends pas compte des consequences que cela peut avoir.
Je peux comprendre que le monde financier a plein d'argents. Quand on veut faire les choses bien, il n'y personne. Par contre quand il y a un truc de genre, les utilisateurs et l'entreprise sont dans le meme bateau meme s'ils y sont pour rien.

Citation:

---

Envoyé par Pyramidev

Dans ce cas, on crée une nouvelle fonction getStrudents et on met l'ancienne fonction getStrudents_canBeNull en dépréciée.
Dans les 8000 établissements de France, ceux qui n'ont pas le temps de maintenir leur vieux code le laissent tel quel et masquent les avertissements de type "dépréciation" s'ils ne l'on pas déjà fait. Ceux qui ont le temps simplifient leur vieux code en changeant progressivement des appels de getStrudents_canBeNull par des appels de getStrudents en supprimant au passage des tests obsolètes de non nullités de référence.

---

Oh les bonnes pratiques…*On déprécie mais on masque le warning car de toutes façons, elle ne sera jamais retirée…*Et puisqu'on masque le warning, vu que le développement est à base de copier/coller, de toutes manières personne ne changera progressivement et continuera à utiliser la fonction qui est déjà utilisée partout. Et surtout, pourquoi changer ? Ça marche, non ? La fonction en elle même a changée à part une modification technique ?

L'idéal n'est-il pas d'avoir une approche que la POO utilise, un concept de fou : l'encapsulation…*On utilise un nom qui explique ce que la fonction fait, juste ça, pas de notions d'implémentation (ça, c'est notre tambouille interne), comme ça, on n'a pas besoin de mettre getStrudents_canBeNull en deprecated car il faut utiliser getStrudents_mayBeNull qui est aussi dépréciée car on a ajouté getStrudents_cannotBeNullAnymore mais qui est déprécié aussi car on a un getStrudents_ifOnlyOneWillNotBeACollection qui n'est pas resté très longtemps, un délire de l'archi, donc c'est déprécié pour un getStrudnts_cannotBeNull mais finalement on l'a aussi déprécié car il y avait une faute d'orthographe donc finalement, il faut utiliser getStrudents_cannotBeNull…

Surtout que la logique…*On pollue le nom avec une considération technique car c'est plus facile pour l'utilisateur que de vérifier la doc de la fonction, mais on suppose qu'il ira vérifier la présence de deprecated mis sous silence…

Citation:

---

Envoyé par MikeRowSoft

ok, je rajoute les requêtes SQL. :)

---

C'est encore autre chose…

Citation:

---

Envoyé par raphchar

L'age changeant chaque année, la fonction setAge est nécessaire, j'ai repris l'exemple fournit, sinon il serait plus pertinant d'indiquer la date de naissance.

---

Ah, parce que, l'âge changeant chaque année, tu affecte la donnée chaque année… Et si on veut savoir quel était l'âge l'année où il a été promu capitaine, on lui affecte cet âge là auparavant…*Évidemment que l'âge est calculé à partir d'une référence comme la date de naissance, c'est un cas d'école de mise en œuvre de l'encapsulation…

Citation:

---

D'ailleurs la classe age peut justement contenir la date de naissance et un pointeur vers la vrai date pour donner l'age véritable. Si on se dit que finalement on va faire comme ça, mais qu'avant on avait des int, il faudra parcourir tout le code à la traque aux âges, sinon, on modifie la classe et voilà! Si l'on modifie le constructeur, c'est simple le compilateur indiquera directement là où il faut faire les modifs.

---

mais WTFunk…

Citation:

---

Après on reste sur un exemple, je ne prétent pas qu'il faille absoluement faire cela. Mais, je suis sûr que certains penserons que c'est une bonne habitude de programmation. D'ailleurs je suis tout à fait certain que tu seras content d'avoir une classe Taille, plutôt qu'un pair d'entier, une classe vec3 ou Vector3d plutôt qu'un tableau de taille 3, sans pour autant ironiser sur le fait d'avoir besoin de Factory.

---

Je ne sais pas ce qui est attendu pour une classe Taille, mais même la notion de "vecteur3d", pourquoi ? Un tableau de taille 3 ? Quelle est la case qui représente x, y et z ? Pourquoi pas un dictionnaire avec les clef x, y et z ? C'est pas suffisant ? Qu'apporte l'objet ?

Sérieux, les bases de la POO, c'est qu'un objet, c'est une entité qui a un état et des comportements. Si tu n'a pas de comportements à gérer, un objet ne sert généralement à rien. Ok, je sais que depuis une bonne dizaine n'année on a une génération de développeurs qui n'ont jamais fait de POO mais comme ils utilisent des langages "objets" ils doivent écrire toutes les données sous forme de classes ce qui nous conduit au concept des "transporteurs de données" alimentés par des Factory (si, si, je maintiens l'ironie… :p ).

Et au final, la discussion vient justement de supposition basées simplement sur le nom d'une méthode car dans un cas comme celui-ci, l'exposition de cette données (âge) résulte d'un besoin métier qui spécifie ce qui est attendu. Je pense donc que tout le monde conviendra qu'il manque juste la doc "Retourne l'âge en année"…

Allez, je fini de rager : au lieu d'un capitaine, on pourrai penser à un Passenger qui pourrai être créé avec une donnée "date de naissance" et exposer une méthode

Code:

---

age(date=None)

---

qui, si date est None, retourne l'âge en années révolues à la date d'aujourd'hui sinon à la date en paramètre. On pourrai fantasmer qu'une agence de voyage utilise ce modèle ce qui permet, après avoir demandé les données au client de déterminer le type de voyageur (bébé, enfant ou plein tarif) plutôt que de l'engueuler parce que non, puisqu'il aura 3 ans au voyage, ce n'est pas un bébé, veuillez recommencer tout le dialogue… Rhâ !!! Donc, il y a besoin d'une classe pour une notion qui en soi se résume en un entier ???

Citation:

---

Envoyé par martopioche

(...)
L'idéal n'est-il pas d'avoir une approche que la POO utilise, un concept de fou : l'encapsulation… (...)

---

Mais on n'a pas attendu la POO pour faire de l'encapsulation...

Je me demande bien sur quel genre de projet tu travailles pour être à ce point limité à une seule manière de concevoir le développement ?

Et cette seule manière est totalement dans l'air du temps...

C'est pour cela que tu n'arrives pas à convaincre tout le monde malgré la "masse" de ton argumentation :
il y a ici des intervenants qui ont vu passer plusieurs "airs du temps". Par exemple pour les commentaires : à une époque on nous disait qu'il fallait absolument qu'il y ait plus de commentaires que de code ; puis on a voulu nous faire croire que mettre des commentaires était nécessairement la preuve qu'on code comme un porc, etc, etc.

Quand on a vu passer plusieurs "airs du temps", on fait confiance à son expérience, et à celle des autres et à leur variété.

C'est plus sain qu'agiter des "bonnes pratiques" comme le ferait un fanatique religieux.

Il y a une citation (je ne sais plus quel en est l'auteur) qui dit :

Citation:

---

"Entre ce que je pense, ce que je veux dire, ce que je crois dire, ce que je dis, ce que vous voulez entendre, ce que vous entendez, ce que vous croyez en comprendre, ce que vous voulez comprendre, et ce que vous comprenez, il y a au moins neuf possibilités de ne pas se comprendre."

---

Avec les programmes informatiques, il doit être possible de doubler le nombre de possibilités de ne pas se comprendre :)

Citation:

---

Envoyé par raphchar

Mais si l'on revient au problème initial, on peut affirmer, que si le code accepte un âge négatif si on ne le veut pas, c'est un bug, pas un manque de documentation.

---

Comme tu obtiens un age négatif sans étudié avant l'an zéro ? Et principalement au carbon 14...
Tu pourrais me donner un exemple d'usage s'il te plait ?
La seule chose que je trouve c'est l'age du capitaine à une date donné avec pour réponse "qu'il n'est pas encore née"...

A croire que poser la bonne question est primordiale... Surtout que même ci tu demande le nombre d'année entre une année bien précise et l'année de naissance du capitaine, que ce sera bien sur une valeur positive.

Citation:

---

Envoyé par Nebulix

[...] taux d'intérêts négatifs.

---

J'aurais juré qu'un taux positif que c'est une plus valus et qu'un taux négatif que c'est un déficit...

D'habitude le vocabulaire veux que les intérêts (le "gagné" en + en banque) soit toujours positifs. C'est vrai que le principe du taux d'intérêt est subtile et un très bon exemple.

P.S. : le "perdu" en - en banque étant aussi très souvent représenté par une valeur positive. :mouarf:

Citation:

---

Envoyé par koyosama

Connais-tu le projet Louvois. Sais-tu les impacts sur les utilisateurs et le monde en general quand ce genre d'anerie arrive ? Tu te rends pas compte des consequences que cela peut avoir.
Je peux comprendre que le monde financier a plein d'argents. Quand on veut faire les choses bien, il n'y personne. Par contre quand il y a un truc de genre, les utilisateurs et l'entreprise sont dans le meme bateau meme s'ils y sont pour rien.

---

Merci de m'avoir ouvert les yeux. Et quand les états renflouent les banques qui ont spéculé n'importe comment, avec l'argent du contribuable et sans contrepartie, c'est toujours le même bateau ?

Citation:

---

Envoyé par SimonDecoline

Merci de m'avoir ouvert les yeux. Et quand les états renflouent les banques qui ont spéculé n'importe comment, avec l'argent du contribuable et sans contrepartie, c'est toujours le même bateau ?

---

Si tu as fait un peu fait d'economie, OUI, oui et encore OUI. C'est un peu desolant de voir ce genre de scenario. Mais croire a la bonte du systeme est tres mignon de ta part ^^.

La societe repose sur des piliers importants. Si tu regardes Mr Robots, tu peux voir un apercu de ce que peut arriver au monde sans un systeme monetaire comme les banque. Ou si tu prefere, ouvre un livre d'histoire et ouvre la page entre Antiquite et Moyen-Age. C'est le meilleur exemple.

Ensuite les etats jouent un drole de jeu avec les banques. Que tu le veux ou pas, la banque est un pilier centrale d'une societe, de la democracie et du pouvoir en place. Je pense que t'a vu dans Game of throne que meme les Lanisters sont plier devant la banque. Tu peux faire comme le roi de France et detuire tous les templiers, mais quel source financiere te fera confiance ?

C'est le systeme le plus pervert. Si tu prends pas des extraits de films et de series. Je te ferais reference a la crise de wall street en 1938 qui causera plus tard la deuxieme guerre mondiale.

Alors oui, a moins on a tous les couilles comme les islandais pour emmerder les banques. La banque est loi, la banque est au dessus des etats et la banque peut definir vie ou de mort sur un etat. En plus tu regarde cette etude, tu verras que la France est specialiste dans le monde financier, on est un peu lie avec ce monde la.

Tu raconte n'importe quoi, les banques au contraire ne sont pas au dessus des états et si on est dans la merde jusqu'au coup c'est justement a cause du faite que les banque soient au dessus des états.

Le problème fondamentale de notre system économique est la création monétaire et sont contrôlé pour le bien de l'humanité et pas pour une minorité.
La dette des pays est une insulte à l’intelligence des gens comment on peut rembourser 150 euros quand on emprunte 100 euros et quand le System il n'y a que 100 euros ????? ben on emprunte 150 euros ????

Mais la révolution est en marche car on vois bien que le system arrive a bout de souffle donc soient les manager/directeur/politique accepte de changer le System soi ça sera la guerre.

Le system idéal est pourtant simple :
L’Europe tous les ans vote un budget (création monétaire ) en fonction de l'inflation de l’année précédente et des besoin d’intérêt public (santé éducation défense ).
Dans ce System plus besoin d'impôts et comment du travail pour tous le monde.
Donc plus besoin de donner des aides , des allocations car tous le monde peut avoir un boulot.

Je suis en train de créer un petit jeux de stratégie pour mettre en évidence que ce modèle fonctionne , pour un objectif simple faire la guerre contre un adversaire

Citation:

---

Envoyé par super_navide

Tu raconte n'importe quoi, les banques au contraire ne sont pas au dessus des états et si on est dans la merde jusqu'au coup c'est justement a cause du faite que les banque soient au dessus des états.

Le problème fondamentale de notre system économique est la création monétaire et sont contrôlé pour le bien de l'humanité et pas pour une minorité.
La dette des pays est une insulte à l’intelligence des gens comment on peut rembourser 150 euros quand on emprunte 100 euros et quand le System il n'y a que 100 euros ????? ben on emprunte 150 euros ????

Mais la révolution est en marche car on vois bien que le system arrive a bout de souffle donc soient les manager/directeur/politique accepte de changer le System soi ça sera la guerre.

Le system idéal est pourtant simple :
L’Europe tous les ans vote un budget (création monétaire ) en fonction de l'inflation de l’année précédente et des besoin d’intérêt public (santé éducation défense ).
Dans ce System plus besoin d'impôts et comment du travail pour tous le monde.
Donc plus besoin de donner des aides , des allocations car tous le monde peut avoir un boulot.

Je suis en train de créer un petit jeux de stratégie pour mettre en évidence que ce modèle fonctionne , pour un objectif simple faire la guerre contre un adversaire

---

Heureusement que la crypto-monaie arrive au secour du citoyen. Enfin une monaie sans controle ni des banques ni des états dont la valeur ne dépends que et exclusivement que du marché.
Pour revenir à la documentation, je dirais que tout se documente et que le code autodescriptif n'existe pas; c'est comme expliquer un problème et sa solution en équations mathématiques et dire qu'il n'y a pas besoin de dire pourquoi cette équation a été choisie plutôt qu'une autre pour pondre un résultat final.
Je peste terriblement sur les gens qui codent en Frotran en me disant que ça n'a pas besoin d'être doccumenté puisque tout est dans le code; j'immagine que ça doit être pareil pour c'eux qui codent en C, Pascal, Assembleur, etc ...
A vos docummentations !

Citation:

---

Envoyé par martopioche

Je ne sais pas ce qui est attendu pour une classe Taille, mais même la notion de "vecteur3d", pourquoi ? Un tableau de taille 3 ? Quelle est la case qui représente x, y et z ? Pourquoi pas un dictionnaire avec les clef x, y et z ? C'est pas suffisant ? Qu'apporte l'objet ?

---

Pourquoi x, y, z et pas r, g, b ? Je crois qu'il y a trois conventions de nommage des vecteurs pour les shaders. Si on prend un dictionnaire, alors dico[x] et dico[r] ne pointerons pas vers le même objet à priori, et si l'on utilise un dico, l'initialisation est lourde et rien n'empêche d'ajouter d'autre éléments. Mathématiquement, un vecteur 3d aura trois coefficiants (float ou autre): le premier, le deuxième et le troisième, donc un tableau est bien mieux si l'on ne veut pas d'encapsulation.
Maintenant, sans encapsulation, je n'aurai pas d'opérateurs mathematiques indispensable pour mes vecteurs (additions, multiplication par un scalaire, produit scalaire, produit en croix, normalisation), ni de méthodes (norme, norme au carrée), donc je devrais implémenter de moches fonction à la C

Code:

---

array[3] add(array[3]& bla, array[3]& toto);

---

C'est stupide car avec une classe, je peux ajouter mes méthodes et opérateurs, je peux cacher ma variable en privée. Je peux utiliser mes conventions de nommage xyz et rgb. Clairement se rabattre sur un array ou un dico, n'est pas satisfaisant. D'ailleurs, les libs que j'utilises ont toutes une classe vecteur.

Citation:

---

Envoyé par super_navide

Tu raconte n'importe quoi, les banques au contraire ne sont pas au dessus des états et si on est dans la merde jusqu'au coup c'est justement a cause du faite que les banque soient au dessus des états.
Le problème fondamentale de notre system économique est la création monétaire et sont contrôlé pour le bien de l'humanité et pas pour une minorité.

---

^^ J'adore ta naivete. Il y a aura jamais de revolution en place. Tout simplement les gens detestent le changement. Le Brexit en ait la preuve vivante, de belle parole pour vouloir revenir en arriere pour certain.
Je pensais comme toi "pour le bien de l'humanite". J'ai vu un peu d'en haut, un peu au milieu et beaucoup d'en bas et dans differents endroit et le bien de l'humanite tu peux l'oublie.
Les points d'histoire que je t'ai cite montre a qu'elle point le systeme ne changera pas. Et je ne suis pas sur que la crypto-monnaie va aider quoi ce soit. En plus le bitcoin a un probleme de performances, peut etre que ce sera euthereum.

Tu peux creer le meilleur system monetaire que tu veux, c'est pas que du virtuel. Tant que l'humanite est evil, tu pourras jamais rien faire. "Je ne vis pas pour travailler, mais je travaille pour vivre", penses-tu vraiment que tout le monde veut sa. Regarde ce qui se passe en Amerique du sud, c'est la famine partout. Je regardais ce documentaire "French-bashing" (il est sur youtube) et montre clairement la difference de mentalite entre un anglais, americain et un francais. J'ai ete un Londres et il y a avait la statue du fondateur de LLyod (grande banque anglaise) a cote l'abbaye de webminster, juste a cote de la statue de Lincoln, Nelson Madela et Gnadhi pour te dire. La France c'est pas le monde et le monde ne veut pas de solution. Il aime le systeme comme il est.

Desole de te le dire mais les banques sont au dessus des etats. Et connait quelqu'un qui peut se payer une monaie de 2500 dollars l'unite, si sa crache tu peux perdre jusqu'a 2500 fois ta mise. La banque travaille pour les grands et pas pour les minorites. Les subprime est la preuve pour toutes les banques que donner de l'argent au pauvre est grostesque (de leur point de vue, pas du moins) et aussi pour la Grece.

Citation:

---

Envoyé par koyosama

Si tu as fait un peu fait d'economie, OUI, oui et encore OUI. C'est un peu desolant de voir ce genre de scenario. Mais croire a la bonte du systeme est tres mignon de ta part ^^.

La societe repose sur des piliers importants. Si tu regardes Mr Robots, tu peux voir un apercu de ce que peut arriver au monde sans un systeme monetaire comme les banque. Ou si tu prefere, ouvre un livre d'histoire et ouvre la page entre Antiquite et Moyen-Age. C'est le meilleur exemple.

Ensuite les etats jouent un drole de jeu avec les banques. Que tu le veux ou pas, la banque est un pilier centrale d'une societe, de la democracie et du pouvoir en place. Je pense que t'a vu dans Game of throne que meme les Lanisters sont plier devant la banque. Tu peux faire comme le roi de France et detuire tous les templiers, mais quel source financiere te fera confiance ?

C'est le systeme le plus pervert. Si tu prends pas des extraits de films et de series. Je te ferais reference a la crise de wall street en 1938 qui causera plus tard la deuxieme guerre mondiale.

Alors oui, a moins on a tous les couilles comme les islandais pour emmerder les banques. La banque est loi, la banque est au dessus des etats et la banque peut definir vie ou de mort sur un etat. En plus tu regarde cette etude, tu verras que la France est specialiste dans le monde financier, on est un peu lie avec ce monde la.

---

C'est bien joli les démonstrations scientifiques à base de séries télé et de stats linkedin mais je ne vois toujours pas en quoi des banques auraient le droit de faire n'importe quoi avec l'argent des autres et pourquoi en plus on devrait les plaindre quand ils doivent payer quelques développeurs pour gérer l'an 2000 ou les taux d'intérêt négatifs.

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"

Le commentaire est souvent une excuse ou une facilité pour laisser du code crade.
Je préfère pas de commentaire à un mauvais commentaire qui va induire en erreur.

Ainsi source autodescriptif = le développeur veille à ce nommer précisément ses intentions, ce qu'il fait, le "comment" et le "quoi"
Le commentaire sera complémentaire pour indiquer le "pourquoi" (choix d'une implémentation plûtot qu'une autre, etc.)
Doc utilisateur (javadoc...) : uniquement pour des API externes/publiques, si boite noire ça peut être utile pour l'équipe de développement mais en général ce sont des spécialistes de ces boites noires donc à quoi bon polluer le code et maintenir une javadoc...
Les tests précis et bien nommés peuvent aussi faire office de documentation, exemples, tutos, notamment pour tout ce qui est "code privé" justement...c'est d'ailleurs ce qui est souvent le plus facilement/nécessairement testable (test unitaire).

Citation:

---

Envoyé par HaraKity

Il y a une citation (je ne sais plus quel en est l'auteur) qui dit :

---

À ma connaissance, elle provient de Bernard Werber (https://fr.wikiquote.org/wiki/Bernard_Werber).