Citation:
Envoyé par
Matthieu Vergne
Un cartouche n'a pas vocation à ne pas être retouché. Au même titre que n'importe quelle partie d'un programme, le cartouche aussi doit être mis à jour quand c'est nécessaire. Aucun programme n'est "bien fait" dès le départ, même pour des programmeurs très expérimentés, sinon c'est un programme qui t'a pris une journée pour un besoin très réduit que tu oublieras dans un coin.
Si ce n'est que ta fonction est créée et utilisée dans un but particulier.
Quelles que soient les modifications ou corrections apportées au code ou à l'algorithme, le but, les arguments et les conditions d'utilisations restent identiques.
Citation:
Par contre, c'est vrai qu'un cartouche n'a pas pour but de dire ce qu'il y a dans la fonction. Typiquement, on a besoin d'effectuer une opération, on définit le prototype de la fonction qui devra s'en charger, on écrit la doc qui décrit les entrées sorties et autres informations utiles à son utilisation (comme cité plus haut), mais ce qu'il y a dedans est du ressort du développeur. Il peut changer le contenu de la fonction comme il veut tant que la fonction fait la même chose.
Exactement
Citation:
Cependant, il sera bon de mettre à jour la doc en cas de changement du prototype (ajout/retrait/modification d'arguments) ou de la valeur de retour par exemple.
Là, on peut très sérieusement discuter...
Sur le type de retour, d'abord: Soit tu changes le type d'un objet polymorphe pour un type plus générique / spécifique compatible, et ton cartouche reste tout à fait valable.
Soit tu changes un "aucune valeur de retour" (void) en une valeur de retour, et tu dois rajouter l'information au cartouche, en effet.
Soit tu changes carrément le type de retour pour quelque chose d'incompatible, et l'on peut se dire que le but et l'utilisation de la fonction deviennent tout à fait différents: Tu ne pourras pas espérer changer le type de retour de ta fonction sans avoir à repasser chaque appel en revue afin de prendre le changement en compte ==> c'est bel et bien une nouvelle fonction qu'il te faut créer (avec le cartouche) si tu veux "simplement" pouvoir disposer de l'information renvoyée dans une situation particulière.
Le retrait "pur et simple" de paramètre, je n'y crois pas, pour la bonne et simple raison que, si tu as estimé qu'un valeur externe était nécessaire au début, elle restera nécessaire quoi qu'il arrive.
Bien sur, tu peux décider de supprimer le paramètre parce qu'il est devenu un membre de la classe, et, effectivement, cela occasionnera une modification du cartouche.
Mais, encore une fois, un tel changement ne sera jamais envisagé à la légère parce qu'il implique de modifier l'ensemble des appels à cette fonction ;)
Je crois un peu d'avantage à l'ajout d'un paramètre à la fonction, sans doute en prenant soin d'y adjoindre une valeur par défaut (pour, justement, éviter d'avoir à repasser tous les appels en revue afin de rajouter le paramètre)
Effectivement, le cartouche devra être mis à jour
Citation:
Cela peut arriver après raffinage ou nettoyage, quand on se rend compte qu'il est préférable d'utiliser par exemple un type d'objet plus adapté ou quand plusieurs arguments se retrouvent déjà intégrés dans une structure de données (on fusionne donc les n arguments en un seul).
C'est sans doute à cela que sert la surcharge des fonctions, non :question:
Si tu veux éviter d'avoir à repasser l'ensemble des appels en revue, tu vas bien sagement laisser l'ancien prototype et l'ancienne implémentation là où ils sont et surcharger ta fonction... en y adjoignant le cartouche adéquat, quitte à ajouter une notion de déprécation au niveau du cartouche de la première version de cette fonction.
Il y a d'ailleurs de fortes chances que la surcharge se "contente" de faire appel à la première version de la fonction en "dispatchant" les arguments qu'elle reçoit ;)
Citation:
Le rôle de la fonction est probablement le plus stable, mais ça peut aussi changer un peu. Dire que ça ne doit pas changer "parce que ça correspond à une autre fonction", c'est une vision extrémiste.
Pas si tu limites les informations données à celles qui importent réellement à l'utilisateur.
Citation:
Les bonnes pratiques c'est une chose, mais il y en a certaines qui sont loin d'être toujours pratiques. On peut être amené à utiliser des pratiques strictes dans le cas où on fait des programmes critiques, mais ça coûte en temps, en effort voire en outils qui s'assurent que c'est respecté. Et ce coût il faut pouvoir le justifier. Si tu fais un programme qui peut bugger sans avoir de conséquences horribles (e.g. jeu vidéo) tu vas éviter de perdre temps et argent dans des pratiques trop rigoureuse.
Est-ce à dire que tu préfères perdre du temps en débuggage :question:
Citation:
Tout les programmes ne visent pas à être utilisés dans des avions. Ou bien quoi, tu vas toujours faire des boucles avec un nombre d'itérations statique pour s'assurer que ça se finit avant un temps donné ?
je n'ai jamais rien dit de tel ;)
Citation:
Prendre le parti du "décide une fois et ne touche plus", même pour le cartouche, c'est rêver les yeux ouverts. Faut rester réaliste. Cependant, une fonction ne change pas comme de "trier une liste" à "afficher une interface", donc c'est évident qu'il y aura une certaine stabilité. En revanche, l'algo utilisé peut changer du tout au tout, par exemple passer d'un tri par insertion à un quicksort. Là on change quasiment tout. Et les commentaires doivent suivre.
Ici l'exemple est simple, il suffit de se dire "ben on efface tout et on recommence, les commentaires avec", mais en général les changements se font progressivement, et les commentaires restent. Par exemple, on passe d'un tri à bulle à un tri milkshake (tri à bulle dans les deux sens). Si les commentaires initiaux considèrent le sens unique mais restent globalement justes, le dév peut oublier de les changer, mais le suivant qui passe croit que c'est un tri à bulle à cause des commentaires et d'une structure globalement ressemblante, mais ne note pas la ligne avec le changement de sens. Et en touchant un truc en pensant bien faire, il fait une bêtise qui décale tout et le tri est corrompu.
De deux choses l'une:
Soit tu as une seule fonction qui effectue le tri, et l'utilisateur n'a strictement pas à savoir quel sorte de tri est utilisé (le but de la fonction est de trier les données).
Soit tu donnes le choix de choisir "en connaissance de cause" tel algorithme de tri plutôt que tel autre, mais, dés qu'on parle de choix, c'est qu'il existe bel et bien deux au moins deux fonctions distinctes, avec des noms distincts, et pour lesquelles on s'attend à ce que le cartouche indique explicitement l'algorithme utilisé.
Seulement, dans ce cas, il tout changement d'algorithme passera par la création d'une nouvelle fonction... et du cartouche correspondant.
Tout cela pour dire qu'il est, effectivement, possible que l'on doive, à un moment ou à un autre en venir à envisager la modification de certains cartouches, mais le besoin de modifications à apporter au cartouche seront beaucoup moins fréquents que les besoin d'apporter des modifications au code et, surtout, la plupart des besoins de modifications seront dus à des décisions de conception, non à des corrections / améliorations de code strico sensu.
