Discussion :

[Pyramidev]

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

je reprends l'exemple d'un discutable

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

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.

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Gulien]

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.

[martopioche]

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…

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

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 ?

[MikeRowSoft]

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.

[raphchar]

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…

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.

[TiranusKBX]

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

[MikeRowSoft]

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.

[HaraKity]

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

"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

[dourouc05]

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).

[martopioche]

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

Sur le plan définition, tout à fait, bien que pour la majorité le principe est associé à la POO. Dans la pratique, écrire une fonction ne consiste pas à faire de l'encapsulation…

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.

Oh, un beau Argumentum ad antiquitatem. Ok.

Pourquoi x, y, z et pas r, g, b ? Je crois qu'il y a trois conventions de nommage des vecteurs pour les shaders.

Et tu va implanter les 3 dans la même classe ?

Si on prend un dictionnaire, alors dico[x] et dico[r] ne pointerons pas vers le même objet à priori

Ah oui…*Ça doit être pas mal à suivre dans le code ça…

et si l'on utilise un dico, l'initialisation est lourde

Ah bon ? Pourquoi ? Plus qu'un objet ?

et rien n'empêche d'ajouter d'autre éléments

Oui, et c'est pas bien ?

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.

Ah mais tout à fait, si au lieu de x, y et z ou r, g et b, tu utilise 0, 1 et 2, un tableau est bien mieux…

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Mais…*Si tu a des fonctions, tu a les opérations mathématiques…*En quoi "moches" ?

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.

Tu peux oui, lesquelles ? Parce que tu n'avait rien exprimé auparavant…

D'ailleurs, les libs que j'utilises ont toutes une classe vecteur.

Oui, une lib. Une lib est écrite pour répondre à des besoins génériques (du métier) non définis. Enfin, si je suis la même logique, tu utilise bien toutes les méthodes des classes définies par tes libs ?

[raphchar]

Et tu va implanter les 3 dans la même classe ?

Et pourquoi pas ?

Ah bon ? Pourquoi ? Plus qu'un objet ?

Bon, ok, si tu écris une fonction f(x,y,z) qui renvoit ton dico initialisé. Mais dans ce cas, tu pers l'intérêt de la POO.

Oui, et c'est pas bien ?

Non, c'est pas bien. Un vecteur 3d est un vecteur 3d, si tu rajoutes des infos comme une 4ème dimension, tu devrais interpréter ton vecteur 3d comme un vecteur 4d et changer le type d'un objet, je ne pense pas que ce soit une bonne pratique. Avec un vecteur 3d, il n'y a pas d'ambiguïté.

Mais…*Si tu a des fonctions, tu a les opérations mathématiques…*En quoi "moches" ?

Tout du moins pas pratique, la POO tu permets d'écrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

vec3 c=a+b

Rien que pour la lisibilité du code, c'est mieux que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

dico c=AddVec3Vec3(dico a,dico b)

Tu remarqueras que l'emploi de dictionnaire utilisé pour représenter un vecteur, avec un array, on peut ce contenter de Add, mais ça ne change pas ma remarque sur la facilité de lecture.
Là je ferais la même remarque, ta façon de faire sans déclarer de classe vecteur, ressemble à du C, et n'utilise pas les concepts de la POO.

Tu peux oui, lesquelles ? Parce que tu n'avait rien exprimé auparavant…

Quelles méthodes ? Tout les opérateurs mathématiques auquels on peut penser. Mais je ne comprends pas cette remarque, pourrais-tu la reformuler ?

Oui, une lib. Une lib est écrite pour répondre à des besoins génériques (du métier) non définis. Enfin, si je suis la même logique, tu utiises bien toutes les méthodes des classes définies par tes libs ?

Oui, mais mon point est que ces libs déclarent des classes vecteurs et ne se contentent pas de réinterpréter une structure existante comme vecteur.

Pour résumer ma vision : créer des classes apporte une plus value au code, tout d'abord en lecture et ensuite en fonctionnalité. Se rabattre sur une classe existante, c'est bien, mais pour y rajouter des opérateurs/opérations spécifiques, il me semble indispensable de créer une nouvelle classe.

[martopioche]

Et pourquoi pas ?

Au hasard, parce que pour une question de lisibilité tu ne mixera pas les 3 ?

Bon, ok, si tu écris une fonction f(x,y,z) qui renvoit ton dico initialisé. Mais dans ce cas, tu pers l'intérêt de la POO.

??? En quoi déporter l'initialisation d'un dictionnaire dans une fonction le rend "moins lourd" que de l'initialiser directement ?

Non, c'est pas bien. Un vecteur 3d est un vecteur 3d, si tu rajoutes des infos comme une 4ème dimension, tu devrais interpréter ton vecteur 3d comme un vecteur 4d et changer le type d'un objet, je ne pense pas que ce soit une bonne pratique. Avec un vecteur 3d, il n'y a pas d'ambiguïté.

? Pas d'ambiguïté de quoi ? Si il y a une 4ème dimension, c'est un 4d, ou plutôt, si il n'y en a pas, ce n'en n'est pas…*En quoi c'est ambigüe ?

Tout du moins pas pratique, la POO tu permets d'écrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

vec3 c=a+b

Rien que pour la lisibilité du code, c'est mieux que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

dico c=AddVec3Vec3(dico a,dico b)

Tu remarqueras que l'emploi de dictionnaire utilisé pour représenter un vecteur, avec un array, on peut ce contenter de Add, mais ça ne change pas ma remarque sur la facilité de lecture.

Pas certain, en quoi

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

validate(a + b)

est plus "lisible" pour comprendre ce qu'on manipule que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

validate(addVectors(a, b))

??? Ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

let c = a + b

est plus lisible que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

let c = addVectors(a, b)

?

Là je ferais la même remarque, ta façon de faire sans déclarer de classe vecteur, ressemble à du C, et n'utilise pas les concepts de la POO.

Quel rapport avec le C ? Alors certes, en C, il est impossible d'utiliser "les concepts de la POO". D'autre part, quel concept ? Celui qui consiste à déclarer des méthodes ? Cela prive-t-il de l'usage de fonctions ?

Quelles méthodes ? Tout les opérateurs mathématiques auquels on peut penser. Mais je ne comprends pas cette remarque, pourrais-tu la reformuler ?

Heu…*un programme informatique est destiné à répondre à un besoin…*Dans ton post d'il y a 4 jours, tu parle juste d'avoir une classe représentant un vecteur plutôt qu'une pair d'entier, à aucun moment tu n'a exprimé un autre besoin que de représenter une pair d'entier et pour ma part, je ne vais pas commencer à faire de la conception de "tout ce que l'on peut penser" sur une simple expression de "représenter une donnée". Ce n'est que le post suivant que tu introduit la notion de shader et uniquement maintenant que tu parle d'opérations entre eux pour aller jusqu'à "tout ce qu'on peut penser"…*La POO n'est pas une poubelle pour l'absence de définition du besoin…

Pour résumer ma vision : créer des classes apporte une plus value au code, tout d'abord en lecture et ensuite en fonctionnalité. Se rabattre sur une classe existante, c'est bien, mais pour y rajouter des opérateurs/opérations spécifiques, il me semble indispensable de créer une nouvelle classe.

Nope ce n'est pas aussi binaire. "Créer une classe" entraine la manipulation d'une notion sous forme d'objet, c'est tout. Une plus value est déduite de la manipulation que tu dois avoir de cette notion. Et je remonte donc à il y a 4 jours, une classe "age", "taille" ou "vecteur3d" qui sert juste à transférer la donnée sous-jacente n'a aucune plus value autre que passer par l'instanciation d'objets afin de faire chauffer les processeurs. C'est une constante sur les 2 posts que je suis depuis quelques jours : tout le monde y va de sa proposition de conception, définir des objets, des injecteurs de dépendances, des factory…*Ah non, ça c'est moi…*Enfin, tout le monde y va d'une conception alors qu'aucun besoin n'est défini…*La plus-value, c'est qu'au final, on a une complexification qui ont au moins l'intérêt de nous garantir du boulôt. Sérieux, un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
ageDuCapitaine = Age.createFromString(input("Quel est l'âge du capitaine ? "))
if 18 < ageDuCapitaine.years < 65:
    print("Le Capitaine a " + ageDuCapitaine.yearsAsString)
else:
    print("Pas possible un capitaine si jeune")

Je ne suis pas certain de la plus-value par rapport à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
ageDuCapitaine = int(input("Quel est l'âge du capitaine ? "))
if 18 < ageDuCapitaine:
    print("Le Capitaine a {}".format(ageDuCapitaine))
else:
    print("Pas possible un capitaine si jeune")

[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

[Jiji66]

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 !

[koyosama]

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.

[deuz59]

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

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).

[TJ1985]

Marrant de lire certains. Durant 25 ans j'ai maintenu du code, forcément ancien, non documenté. Et j'ai aussi écrit quelques applications, en divers langages. Conclusion : Le code doit utiliser un nommage clair, c'est impératif. Ensuite, expliquer pourquoi on choisit telle option plutôt que telle autre pour implémenter une fonction/méthode est fondamental. Et ça doit se trouver en tête de fonction, pas quelque part dans une doc perdue je ne sais où.
Donc je suis d'accord avec l'auteur de l'article original. On peut bien sûr préférer une doc structurée, à jour, accessible. Ça doit exister dans certaines structures, bien organisées, où la planification est établie et respectée. En pratique je n'ai jamais rencontré ce type d'environnement.
Enfin, il devrait être possible d'utiliser les liens hyper-textes à partir du source pour remonter à une doc sur un serveur http. Je ne sais pas si ça existe, ce serait incitatif.
Post scriptum : Swift permet un nommage précis des arguments et Apple insiste sur l'utilisation de noms longs et descriptifs à tous les niveaux. Expérience faite, c'est vrai que le système de double nommage externe/interne clarifie le propos lorsqu'il est applicable. Mais on peut toujours écrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

func toto(a b: String)-> String

...

[martopioche]

Post scriptum : Swift permet un nommage précis des arguments et Apple insiste sur l'utilisation de noms longs et descriptifs à tous les niveaux. Expérience faite, c'est vrai que le système de double nommage externe/interne clarifie le propos lorsqu'il est applicable. Mais on peut toujours écrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

func toto(a b: String)-> String

...

Grand fou, le double nommage à la Apple…*:p

[cedric57]

Moi perso dans la plupart des cas…je comprendrai plus vite le code en le faisant fonctionner avec un débogueur ou encore en ajoutant des messages de log. Ensuite je trouve la doc utile quand le code n'est pas simple à compiler / exécuter…ou encore pour comprendre les workarounds / morceaux de code pas intuitifs.
Sinon j'invite les défenseurs de la doc ultra complète à se poser les questions suivantes:
- Entre doc ultra complète et pas de doc, ne peut-il pas avoir un juste milieu? Cela ne dépendrait-il pas du projet en question?
- Pourquoi les hackers n'ont pas besoin de doc…ni de code pour comprendre comme marche un système avant de le hacker?
- Pourquoi existe-t-il des projets open source conséquents peu documentés mais qui évoluent très bien?
- Le débogueur et l'ajout de message à un code bien écrit ne peut-il pas souvent être un bonne alternative à la doc?
- Quand on est limité par le temps, faut-il mieux moins bien coder ou sacrifier la doc?
- Quand on recrute un développeur peu expérimenté ou peu motivé dans un projet complexe non documenté…le problème est-il vraiment du à un manque de doc? Ce développeur pourrait-il facilement reprendre facilement un autre projet complexe mais bien documenté comme gmail?

[Invité]

Perso, étant un n00b en programmation, j'ai appris en regardant le code des autres et je ne partage pas du tout l'avis de l'article.

Des variables, méthodes et class bien nommées m'ont été 1000x plus utile que les commentaires qui sont une vrai gène pour comprendre le code et la façon de penser de celui qui l'a créé.

Je pars souvent de logiciel open source pour réécrire les miens et mon premier reflex est d'effacer 99% des commentaires qui sont totalement inutile et font perdre un temps fou.

Je ne suis pas un dev pro, juste quelqu'un qui a décidé de s'y mettre parce que j'en avais marre de la pub/flicage/vol de données alors l'argument du "il faut penser au débutant", pour moi, ne tient absolument pas la route.

Au final, je fais ce qui m'a paru le plus facile pour comprendre du code, bien nommer et un minimum de commentaires. Un code bien propre propre est franchement plus agréable et facile à appréhender qu'un truc documenté.