Moumou
:

Pollux :
Ne pas dupliquer l'information : de même que, je sais pas, en C tu évites de dupliquer l'information qu'est la longueur d'un buffer de taille fixe et tu utilises un #define plutôt qu'une constante hardcodée...

Oui, parce que la longueur du buffer peut changer. Tandis que le dit type, lui, ne changera pas, sauf si tu ne te sers pas de ce type pour sa sémantique à lui mais parce qu'il remplit le rôle d'une interface quelconque.

Ah bon, c'est rare de devoir changer le type d'une variable
Je sais pas moi, c'est courant de devoir changer un std::vector (tableau dont on peut efficacement insérer/supprimer des éléments seulement à la fin) en std::deque (tableau dont on peut efficacement insérer/supprimer des éléments à chacun des deux bouts), puis ensuite peut-être qu'on peut avoir besoin d'évoluer vers un tableau "sparse" parce qu'il y aura en fait des trous avec pleins de zéros consécutifs...

Pollux :
1] si je veux changer le type d'une variable qui est recopié un peu partout, comment l'IDE peut savoir quels endroits devraient effectivement être changés ?

Je ne vois pas bien ce que tu veux dire, en quoi aliaser un type t'aiderait à changer le type de la dite variable ?

De la même façon qu'aliaser "42" en "buffer_size" te permet de changer plus facilement la taille de ton buffer si elle est utilisée à plusieurs endroits...

Pollux :
2] ça n'améliorerait pas la lisibilité

Ben je vois pas en quoi ça améliorerait la lisibilité de renommer List<Couple<String,Int>> en PlopProut si effectivement tu t'en sers uniquement comme d'un List<Couple<String,Int>>. Justement, ça demanderait de revenir chercher les informations à l'endroit de la définition du type.

De même qu'écrire
const int buffer_size = 42;
n'a évidemment aucun intérêt puisque je ne me sers de buffer_size que comme de 42. En plus, c'est encore pire, parce que 42, on voit du premier coup d'oeil que c'est un entier, alors que "buffer_size", on est obligé de revenir chercher des informations à l'endroit de la définition de la variable Les constantes, çay mal, hardcodez tout


Malheureusement si on veut éviter la duplication tout en faisant en sorte qu'on puisse voir du premier coup d'oeil la définition, il faut que le code source soit un DAG et pas un arbre