Domanda

Ho giocato con il Codice dei Contratti su VS2008http://msdn.microsoft.com/en-us/devlabs/dd491992.aspx).
Sicuramente sono belle e fornire una solida alternativa a se-poi-gettare i controlli all'interno di metodi.

Comunque ho sperato che potessero soddisfare il bisogno che sento forte per non nullable tipi di riferimento.
Purtroppo, da quello che ho potuto vedere, questo non sembra essere il caso.
Questo è quello che ho capito io:

  • Qualcosa di simile a questo sarà ancora causare problemi in fase di runtime:
    MyClass a = null;
    a.ToString();

  • Devo ancora scrivere esplicitamente i controlli, anche se in modo più conciso e metodo razionale.

  • A meno che non si utilizza VS Team System è possibile utilizzare solo i contratti di codice per controllare le cose in fase di esecuzione, senza benefici in fase di compilazione.
    Il che significa che avete ancora a gestire le cose quando qualcosa va storto.
    Non e ' molto diversa dalla manipolazione di una semplice eccezione.

  • Anche con VSTS analisi statica non è così buono come quello fatto in fase di runtime.
    Questo è perfettamente comprensibile, è ancora un altro segno che questa funzione è stata progettata per la fase di esecuzione l'uso.

Per favore mi corregga se sbaglio, ma da quello che vedo non c'è modo di Contratti di Codice può rendere la vita più facile, e la mia programmi più robusti, come non nullable di riferimento i tipi.

Non fraintendetemi, non disdegno codice dei contratti.
Che sono un bel miglioramento per l'intero quadro.
E ' solo che se questo non colmare il divario che C# foglie non avendo non nullable tipi di riferimento, a questo punto ho paura che niente.
Voi cosa ne pensate?

È stato utile?

Soluzione

Penso che tu abbia ragione riguardo questo.Non nullable di riferimento per il controllo in fase di compilazione è stata la caratteristica killer stavo aspettando nel Codice dei Contratti, e non è davvero lì.

Per quelli che si chiedevano che cosa questo significa, prendere in considerazione un'analogia con i tipi di valore.Non erano nullable in origine, ma ora sono se si mette un punto di domanda dopo il nome del tipo:

int? n;

Per coerenza sarebbe l'ideale se lo stesso era vero per i tipi di riferimento.Ma che si rompono tutti gli attuali programmi C# e quindi non è un'opzione.Nella ricerca della lingua Spec# sono andato con l'utilizzo di un punto esclamativo suffisso significa non nullable:

string! s = "Hello";

Come con le normali tipi di valore, il compilatore in modo statico) controlla che string! variabile non viene utilizzato su qualsiasi percorso di codice prima di esso è stato inizializzato (credo Spec# richiede la dichiarazione e l'inizializzazione si verificano nella stessa dichiarazione).

Essa vieta anche l'assegnazione di null a tale variabile.

E, naturalmente, non vieta l'assegnazione di un normale string per un string!.Così come colmare il divario tra i due tipi di tipo?Scrivendo un controllo:

string x = GetStringFromSomewhere();

if (x != null)
    s = x; // okay because compiler sees null check

La triste verità è che la maggior parte delle variabili di riferimento nella maggior parte dei programmi sono suscettibili di essere non annullabile se il programma è corretto.Nullable variabili sono in minoranza.E, tuttavia, essi sono predefinite.

Un'altra cattiva idea dal 1960!

Altri suggerimenti

Io non sono sicuro di quale problema si è risolto da "non nullable tipi di riferimento".Ok, quindi questo codice è molto meno probabile che genera un'eccezione:-

a.ToString();

Tuttavia è più probabile che sia corretto perché non annullabile?Quale sarebbe il valore iniziale di a?Probabilmente alcuni di default "Vuoto" istanza del tipo.In questo caso non è più probabile che per rendere le cose più difficili da eseguire il debug in quanto i valori che devono stato assegnato un valore non.Solo avere qualche comportamento di default invece di causare un'eccezione non suona come qualcosa che voglio.

Penso che il concetto di non nullable tipo di riferimento potrebbe essere davvero utile per ORM generato proprietà sulla mappa per campi di database.Spesso non si riesce a dire dalla proprietà (di solito di tipo stringa) se il sottostante campo di valori null o non.Con nullable tipi di valore, si può, semplicemente cercando il punto di domanda.

Io non sono troppo preoccupato per verifica statica, a parte ovvio pippo!= null;in mancanza, ma l'intellisense sarebbe molto utile come suggerimento per variabile intento, credo.

Non nullable di riferimento per il controllo in fase di compilazione è stata la caratteristica killer stavo aspettando nel Codice dei Contratti, e non è davvero lì.

Aggiornamento 2017 (8 anni dopo), mentre Non nullable tipo di riferimento ancora non c'è...nullable tipo di riferimento potrebbe.

Mads Torgersen (Linguaggio C# PM a Microsoft) fa menzione di esso in questo tweet:

Il prototipo di nullable tipi di riferimento è finalmente qui!

Questo è cartina in "L'introduzione di Nullable Tipi Riferimento in C#"e in questo video "nuove funzionalità disponibili C# 7.1 e 7.2".

Questo può essere raggiunto se invece aggiungiamo solo una nuova “cassetta di sicurezza” tipo di tipo di riferimento, e quindi reinterpretare esistente tipi di riferimento come gli altri “sicuro” in genere.Più specificamente, pensiamo che il default significato di non annotate i tipi di riferimento come stringa dovrebbe essere non nullable tipi di riferimento, per un paio di motivi:

Noi crediamo che è più comune il desiderio di un riferimento non essere null.Nullable tipi di riferimento sarebbe il tipo più raro (anche se non abbiamo dati a dirci da quanto), quindi sono quelli che dovrebbe richiedere una nuova annotazione.Il linguaggio, che è un concetto e di una sintassi per nullable i tipi di valore.L'analogia tra i due sarebbe rendere la lingua oltre che concettualmente più semplice, e linguisticamente più semplice.
Mi sembra giusto che non si deve onere di te o il tuo consumatore ingombrante valori null a meno che non hai attivamente deciso che si desidera.Null, non l'assenza di essi, deve essere la cosa che ti esplicitamente necessario optare per.
Ecco come si presenta:

class Person
{
    public string FirstName;   // Not null
    public string? MiddleName; // May be null
    public string LastName;    // Not null
}

Questa classe è ora in grado di manifestare la propria volontà che ognuno di noi ha un prima e un cognome, ma solo alcune persone hanno un nome.

Così otteniamo per la chiamiamo questa caratteristica del linguaggio “nullable tipi di riferimento”:Questi sono quelli che vengono aggiunte al linguaggio.Il che non supporta valori null quelli ci sono già, almeno dal punto di vista sintattico.

Questo è ancora un prototipo, e potrebbe finire (o non) nel linguaggio.
Per saperne di più vedere "Il C# Nullable Tipi Di Riferimento Anteprima".

piuttosto che usare null, è possibile utilizzare il valore predefinito come stringa.vuoto non c'è bisogno di null

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top