Arguments nommés (paramètres) comme aide à la lisibilité

Il y a longtemps, j'avais beaucoup programmé dans ADA, et il était normal de nommer des arguments lors de l'appel d'une fonction - SomeObject.DoSomething (SomeParameterName => someValue);

Maintenant que C # prend en charge les arguments nommés, je pense à revenir à cette habitude dans des situations où il n'est pas évident de savoir ce que signifie un argument.

Vous pourriez faire valoir que la signification d'un argument devrait toujours être évidente, mais si vous avez un argument booléen et que les appelants passent "vrai" ou "faux", la qualification de la valeur avec le nom rend le site d'appel plus lisible.

contentFetcher.DownloadNote (remarque, manuel: vrai);

Je suppose que je pourrais créer des énumérations au lieu d'utiliser vrai ou faux (manuel, automatique dans ce cas).

Que pensez-vous de l'utilisation occasionnelle d'arguments nommés pour faciliter la lecture du code?

Cela a été suggéré dans le développement de C ++, et Stroustrup en discute dans son "Design and Evolution of C ++", pages 153 et suivantes. La proposition était bien formulée et s'appuyait sur une expérience antérieure avec Ada. Il n'a pas été adopté.

La principale raison était que personne ne voulait encourager les fonctions avec un grand nombre de paramètres. Chaque fonctionnalité supplémentaire dans une langue coûte quelque chose, et il n'y avait aucun désir d'ajouter une fonctionnalité pour faciliter l'écriture de mauvais programmes.

Cela a également soulevé des questions sur les noms des paramètres canoniques, en particulier dans la convention habituelle des en-têtes et des fichiers de code. Certaines organisations avaient des noms de paramètres plus longs et plus descriptifs dans le fichier .h, et des noms plus courts et plus faciles à taper dans le fichier .cpp (substituez les suffixes de fichier selon vos besoins). Exiger qu'ils soient les mêmes serait un coût supplémentaire pour la compilation, et le fait de mélanger les noms entre les fichiers source pourrait provoquer des bogues subtils.

Il peut également être géré en utilisant des objets plutôt que des appels de fonction. Au lieu d'un appel GetWindow avec une douzaine de paramètres, créez une classe Window avec une douzaine de variables privées et ajoutez des setters si nécessaire. En enchaînant les setters, il est possible d'écrire quelque chose comme my_window.SetColor(green).SetBorder(true).SetBorderSize(3);. Il est également possible d'avoir différentes fonctions avec différentes valeurs par défaut qui appellent la fonction qui fait le travail.

Si vous êtes simplement inquiet de l'effet de la documentation contentFetcher.DownloadNote(note, manual : true);, vous pouvez toujours écrire quelque chose comme ça contentFetcher.DownloadNote(note, /* manual */ true);, donc ce n'est même pas très utile dans la documentation.

Je pense qu'il s'agit de rendre le mauvais code plus lisible, plutôt que la «meilleure pratique».

Avoir une méthode (ou un entrepreneur) qui prend 20 paramètres est une «mauvaise odeur» et est probablement due à un problème dans votre conception. Cependant, si je suis obligé de travailler sur du code lorsque les méthodes prennent beaucoup de paramètres, le paramètre nommé rend le code moins difficile à comprendre.

Lorsque les méthodes n'ont que 1 ou 2 paramètres et que le nom de la méthode indique clairement le paramètre, le paramètre nommé n'ajoute rien. C'est le cas idéal pour être.

Si tout le code sur lequel vous travaillez est écrit selon le livre « code propre », vous n'aurez que très peu recours aux paramètres nommés, mais nous vivons dans le monde réel.

Je suis d'accord que l'ajout du nom du paramètre le rend plus lisible. Cependant, la plupart des livres que j'ai lus semblent considérer les commutateurs booléens comme une mauvaise pratique. Je fais parfois ceci:

public Content DownloadNote(Note note)
{
    return downloadNote(note, manual: false);
}

public Content DownloadNoteManually(Note note)
{
    return downloadNote(note, manual: true);
}

Cela vous donne plus de flexibilité lors de la mise en œuvre de votre API. Il vous permet également de contrôler le cas où vous avez plusieurs commutateurs booléens, mais tous ne peuvent pas être actifs en même temps.

Je suis un grand partisan des paramètres nommés dans des situations où les types et la sémantique ne sont pas clairs d'après le nom de la méthode. D'après mon expérience, peu de gens lisent la documentation.

Cela étant dit, les paramètres nommés ne devraient pas être une alternative à la création de listes d'arguments sensées, à l'utilisation d'objets auxiliaires (pour «lier» des arguments sémantiquement liés) et à l'utilisation d'énumérations, le cas échéant.

Je pense que cela est plus utile dans les langages non-OO, où vous pouvez avoir une fonction qui doit faire quelque chose de plusieurs manières légèrement différentes, et la façon dont elle détermine quoi faire est basée sur les valeurs des paramètres. Dans le monde OOP, nous surchargerions simplement la fonction, mais quand ce n'est pas possible, vous finirez par passer un tas de drapeaux (ou un tas de valeurs, et si elles sont passées ou non est le drapeau).

Je pense que c'est plus lisible, dans une certaine mesure; mais comme d'autres l'ont mentionné, avoir de nombreux paramètres est une odeur de code, donc je ne vois pas beaucoup d'utilisation pour cela dans un langage orienté objet comme C #.