Pourquoi ne pas annoter les paramètres des fonctions?

Pour répondre à cette question, supposons que le coût de l'ambiguïté dans l'esprit d'un programmeur soit beaucoup plus cher que quelques frappes supplémentaires.

Compte tenu de cela, pourquoi laisserais-je mes coéquipiers s'en tirer sans annoter leurs paramètres de fonction? Prenez le code suivant comme exemple de ce qui pourrait être un morceau de code beaucoup plus complexe:

let foo x y = x + y

Maintenant, un examen rapide de l'info-bulle vous montrera que F # a déterminé que vous vouliez que x et y soient des entiers. Si c'est ce que vous vouliez, alors tout va bien. Mais je ne sais pas si c'est ce que vous vouliez. Et si vous aviez créé ce code pour concaténer deux chaînes ensemble? Et si je pense que vous vouliez probablement ajouter des doubles? Ou si je ne veux pas avoir à passer la souris sur chaque paramètre de fonction pour déterminer son type?

Prenons maintenant ceci comme exemple:

let foo x y = "result: " + x + y

F # suppose maintenant que vous avez probablement l'intention de concaténer des chaînes, donc x et y sont définis comme des chaînes. Cependant, en tant que pauvre schmuck qui gère votre code, je pourrais regarder cela et me demander si vous aviez peut-être l'intention d'ajouter x et y (ints) ensemble, puis d'ajouter le résultat à une chaîne à des fins d'interface utilisateur.

Certes, pour de tels exemples simples, on pourrait laisser tomber, mais pourquoi ne pas appliquer une politique d'annotation de type explicite?

let foo (x:string) (y:string) = "result: " + x + y

Quel mal y a-t-il à être sans ambiguïté? Bien sûr, un programmeur pourrait choisir les mauvais types pour ce qu'il essaie de faire, mais au moins je sais qu'ils le voulaient, que ce n'était pas seulement une erreur.

C'est une question sérieuse ... Je suis encore très nouveau sur F # et je trace la voie pour mon entreprise. Les normes que j'adopterai seront probablement la base de tout futur codage F #, intégré dans le copier-coller sans fin qui, j'en suis sûr, imprègnera la culture pour les années à venir.

Donc ... y a-t-il quelque chose de spécial dans l'inférence de type F # qui en fait une fonctionnalité précieuse à conserver, à annoter uniquement lorsque cela est nécessaire? Ou les experts F # ont-ils l'habitude d'annoter leurs paramètres pour des applications non triviales?

Je n'utilise pas F #, mais dans Haskell, il est considéré comme une bonne forme pour annoter (au moins) les définitions de niveau supérieur, et parfois les définitions locales, même si le langage a une inférence de type omniprésente. Ceci pour plusieurs raisons:

• Lecture
  Lorsque vous voulez savoir comment utiliser une fonction, il est extrêmement utile d'avoir la signature de type disponible. Vous pouvez simplement le lire, plutôt que d'essayer de le déduire vous-même ou de compter sur des outils pour le faire pour vous.

• Refactorisation
  Lorsque vous souhaitez modifier une fonction, le fait d'avoir une signature explicite vous donne l'assurance que vos transformations préservent l'intention du code d'origine. Dans un langage déduit par type, vous pouvez constater que le code hautement polymorphe vérifie la typologie mais ne fait pas ce que vous vouliez. La signature de type est une «barrière» qui concrétise les informations de type au niveau d'une interface.

• Performances
  Dans Haskell, le type inféré d'une fonction peut être surchargé (par le biais de classes de type), ce qui peut impliquer une répartition d'exécution. Pour les types numériques, le type par défaut est un entier à précision arbitraire. Si vous n'avez pas besoin de la généralité complète de ces fonctionnalités, vous pouvez améliorer les performances en spécialisant la fonction au type spécifique dont vous avez besoin.

Pour les définitions locales, les letvariables liées et les paramètres formels des lambdas, je trouve que les signatures de type coûtent généralement plus cher en code que la valeur qu'elles ajouteraient. Donc, dans la révision du code, je vous suggère d'insister sur les signatures pour les définitions de niveau supérieur et de simplement demander des annotations judicieuses ailleurs.

Jon a donné une réponse raisonnable que je ne répéterai pas ici. Je vais cependant vous montrer une option qui pourrait satisfaire vos besoins et dans le processus, vous verrez un type de réponse différent d'un oui / non.

Dernièrement, j'ai travaillé avec l'analyse à l'aide de combinateurs d'analyseurs. Si vous connaissez l'analyse, vous savez que vous utilisez généralement un lexer dans la première phase et un analyseur dans la deuxième phase. Le lexer convertit le texte en jetons et l'analyseur convertit les jetons en AST. Maintenant que F # est un langage fonctionnel et que les combinateurs sont conçus pour être combinés, les combinateurs d'analyseur sont conçus pour utiliser les mêmes fonctions à la fois dans le lexeur et dans l'analyseur, mais si vous définissez le type des fonctions de combinateur d'analyseur, vous ne pouvez les utiliser que pour lex ou pour analyser et pas les deux.

Par exemple:

/// Parser that requires a specific item.

// a (tok : 'a) : ('a list -> 'a * 'a list)                     // generic
// a (tok : string) : (string list -> string * string list)     // string
// a (tok : token)  : (token list  -> token  * token list)      // token

ou

/// Parses iterated left-associated binary operator.


// leftbin (prs : 'a -> 'b * 'c) (sep : 'c -> 'd * 'a) (cons : 'd -> 'b -> 'b -> 'b) (err : string) : ('a -> 'b * 'c)                                                                                    // generic
// leftbin (prs : string list -> string * string list) (sep : string list -> string * string list) (cons : string -> string -> string -> string) (err : string) : (string list -> string * string list)  // string
// leftbin (prs : token list  -> token  * token list)  (sep : token list  -> token  * token list)  (cons : token  -> token  -> token  -> token)  (err : string) : (token list  -> token  * token list)   // token

Étant donné que le code est protégé par des droits d'auteur, je ne l'inclurai pas ici, mais il est disponible sur Github . Ne le copiez pas ici.

Pour que les fonctions fonctionnent, elles doivent être laissées avec les paramètres génériques, mais j'inclus des commentaires qui montrent les types inférés en fonction de l'utilisation des fonctions. Cela facilite la compréhension de la fonction de maintenance tout en laissant la fonction générique à l'usage.

Le nombre de bugs est directement proportionnel au nombre de caractères dans un programme!

Ceci est généralement indiqué comme le nombre de bogues étant proportionnel aux lignes de code. Mais avoir moins de lignes avec la même quantité de code donne la même quantité de bogues.

Donc, même s'il est agréable d'être explicite, tout paramètre supplémentaire que vous saisissez peut entraîner des bogues.