Perché non annotare i parametri della funzione?

Non uso F #, ma in Haskell è considerata una buona forma per annotare (almeno) definizioni di alto livello e talvolta definizioni locali, anche se la lingua ha inferenza di tipo pervasivo. Questo è per alcuni motivi:

• Lettura
  Quando vuoi sapere come usare una funzione, è incredibilmente utile avere la firma del tipo disponibile. Puoi semplicemente leggerlo, piuttosto che cercare di dedurlo da solo o affidarti a strumenti per farlo per te.

• refactoring
  Quando vuoi modificare una funzione, avere una firma esplicita ti dà la certezza che le tue trasformazioni mantengono l'intento del codice originale. In una lingua con deduzione di tipo, potresti scoprire che il codice altamente polimorfico eseguirà il controllo tipografico ma non eseguirà ciò che hai inteso. La firma del tipo è una "barriera" che concretizza le informazioni di tipo su un'interfaccia.

• Performance
  In Haskell, il tipo inferito di una funzione può essere sovraccaricato (a titolo di typeclass), il che può implicare una distribuzione in runtime. Per i tipi numerici, il tipo predefinito è un numero intero di precisione arbitraria. Se non hai bisogno della completa generalità di queste funzionalità, puoi migliorare le prestazioni specializzando la funzione in base al tipo specifico di cui hai bisogno.

Per le definizioni locali, le variabili let -bound e i parametri formali per lambdas, trovo che le firme di tipo di solito costano di più nel codice rispetto al valore che aggiungerebbero. Pertanto, nella revisione del codice, ti suggerisco di insistere sulle firme per le definizioni di massimo livello e di chiedere semplicemente annotazioni giudiziose altrove.

Jon ha dato una ragionevole risposta che non ripeterò qui. Ti mostrerò comunque un'opzione che potrebbe soddisfare le tue esigenze e nel processo vedrai un diverso tipo di risposta diverso da un sì / no.

Ultimamente ho lavorato con l'analisi usando i combinatori di parser. Se conosci l'analisi, sai che in genere usi un lexer nella prima fase e un parser nella seconda fase. Il lexer converte il testo in token e il parser converte i token in un AST. Ora che F # è un linguaggio funzionale e i combinatori progettati per essere combinati, i combinatori di parser sono progettati per utilizzare le stesse funzioni sia nel lexer che nel parser, ma se si imposta il tipo per le funzioni del combinatore di parser è possibile utilizzarli solo per lex o per analizzare e non entrambi.

Ad esempio:

/// 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

o

/// 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

Poiché il codice è copyright, non lo includerò qui, ma è disponibile all'indirizzo Github . Non copiarlo qui.

Affinché le funzioni funzionino, devono essere lasciati con i parametri generici, ma includo commenti che mostrano i tipi dedotti a seconda delle funzioni utilizzate. Ciò semplifica la comprensione della funzione per la manutenzione lasciando la funzione generica per l'uso.

Il numero di bug è direttamente proporzionale al numero di caratteri in un programma!

Di solito viene indicato come il numero di bug che è proporzionale alle linee di codice. Ma avere meno linee con la stessa quantità di codice dà la stessa quantità di errori.

Quindi, mentre è bello essere espliciti, qualsiasi altro parametro digitato può portare a bug.