Che cos'è una buona convenzione di denominazione per i tipi generici in C #? [chiuso]

In effetti è soggettivo ... ish .
Poiché alcune persone trovano che i è perfettamente valido per una variabile ciclo for, alcuni pensano che T sia perfettamente valido per un tipo segnaposto in una classe generica.

Personalmente condivido questo approccio, è una convenzione comune e le persone generalmente sanno cosa intendi.

Dove il tipo è significativo, userei un nome significativo, ma in genere lo inizi con T. Ho recentemente sviluppato una classe dizionario generica (non chiedere) e la dichiarazione era

public class Dictionary<TKey, TValue>

Tuttavia, per qualcosa come una tupla, in cui i tipi sono sostanzialmente privi di significato, considero perfettamente accettabili i seguenti.

public class Tuple<T1, T2, T3>

Penso che tu abbia ragione, sebbene T sia diventato piuttosto uno standard. Probabilmente ha origine dai vecchi tempi di C ++ e dalla dicitura "di tipo T". Considero una buona pratica essere il più descrittiva possibile, ma è soggettiva.

Potresti scegliere T come prefisso, proprio come molte persone scelgono I per le interfacce. Così

class Juice<TFruit> where TFruit...

sarebbe un buon nome a mio modesto parere. Preferisco i prefissi ai suffissi nella maggior parte dei casi, poiché è immediatamente chiaro ciò che si vede quando ci si imbatte in esso ed è più facile cercare con cose come Intellisense. È buona pratica anche per i controlli UI, quando molto probabilmente conosci sempre il tipo (ad esempio TextBox) ma non sei sicuro al 100% del nome descrittivo che hai fornito.

Il lato negativo di questo è che sembra scadente quando il tipo stesso inizia con T. Quindi penso che sarebbe un buon suffisso il tipo generico in casi speciali, come quello qui sotto.

class SomeAlgorithm<TypeT> where TypeT : Type

Si noti che questa è solo la mia opinione e molto soggettiva. Ma penso di avere un punto minore, preferendo il prefisso al suffisso.

Microsoft ha una linea guida ufficiale sui generici: Nomi di classi, strutture e interfacce ( citato qui e in forma di libro: Framework Design Guidelines ).

Riguardo alla tua domanda specifica dice:

Do name generic type parameters with descriptive names, unless a single-letter name is completely self explanatory and a descriptive name would not add value.

IDictionary<TKey, TValue> 

is an example of an interface that follows this guideline.

Consider using the letter T as the type parameter name for types with one single-letter type parameter.

Do prefix descriptive type parameter names with the letter T.

Consider indicating constraints placed on a type parameter in the name of parameter. For example, a parameter constrained to ISession may be called TSession.

L'intero punto dei generici è delegare funzionalità - la classe generica fa una cosa, la sua argomentazione fa un'altra. L'esempio da manuale è una raccolta generica: la raccolta immagazzina "cose", ma non gli importa cosa siano queste cose. Un nome generico (sic!), Quindi, ha una certa logica: non vogliamo che sia descrittivo, perché non c'è nulla da descrivere se non "è l'argomento di tipo generico", che il nome T comprende esaustivamente (considerando la convenzione). Essere descrittivi è buono, ma essere troppo descrittivi suggerisce restrizioni che non ci sono.

A volte, tuttavia, una classe generica o un metodo ha più di un parametro di tipo e, a questo punto, ha senso dare loro nomi più descrittivi, in modo che il loro ruolo diventi ovvio. Un buon esempio potrebbe essere per un tipo di raccolta di valori-chiave, in cui sia la chiave che il valore sono generici; chiamarli T e S (o Q o qualsiasi altra cosa) sarebbe meno utile di chiamarli, diciamo, KeyType e ValueType , o TKey e TVal .

La risposta è davvero soggettiva. Tuttavia, ha il merito come una domanda, in quanto il codice dovrebbe autocorreggersi e potremmo eventualmente imparare alcuni modi migliori per farlo.

Le seguenti sono le convenzioni che ho imparato e seguo:

• I parametri di tipo generico non dovrebbero mai essere confusi con classi concrete. Questo generalmente incoraggia una prefazione di T indipendentemente da ciò che segue, proprio come le interfacce sono generalmente precedute da I .

• Un singolo parametro di tipo generico su una classe o un metodo dovrebbe di solito essere etichettato T . Questa è una convenzione quasi universalmente comprensibile che risale ai modelli C ++.

• Più parametri di tipo generico sulla stessa dichiarazione di classe o di metodo dovrebbero iniziare tutti con T, ma essere differenziati con alcuni mezzi concisi ma comprensibili. TIn e TOut , ad esempio, sono GTP comuni e ben compresi per un metodo che accetta un input generico strongmente tipizzato e produce un output generico strongmente tipizzato.

• Tipi multipli differenziati ma insignificanti, come per una classe contenente come Tuple .Net o tipi di delegati come Func, Predicate e Action, possono essere etichettati come T1, T2, T3, ecc. Tuttavia, dichiarazioni GTP "notevoli" (avendo uno scopo definito e / o restrizioni di tipo molto specifiche) dovrebbe avere qualcosa di più descrittivo.

• Un singolo tipo generico su un metodo, che differisce dal tipo generico di una classe contenente, può seguire la regola precedente relativa a più tipi in una classe o un metodo, OPPURE se il tipo è insignificante diverso dall'essere diverso può essere data una singola lettera diversa, spesso U o V . Questa è di nuovo una convenzione che risale ai modelli C ++.

• Qualunque cosa tu scelga di fare, mantienila coerente; non etichettare un GTP per una classe T e il successivo TParam , a meno che la seconda classe non sia nidificata nel primo modo T non disponibile per l'uso nel secondo.