Perché non dichiarazioni che non fanno nulla un'eccezione (o avvertire lo sviluppatore)?

Question

Sono stato morso un paio di volte con dichiarazioni in VB.NET (non so se questo effetto esiste in C #), che sembrano essere autoreferenziale, ma quando sono eseguiti, in realtà non fanno nulla perché richiedono un obiettivo e non è fornito. Ad esempio:

Dim MyString as string = "String to test"

' Neither of these lines do anything '
MyString.Replace(" ", "-")
MyString.Substring(0,5)

' This will return the original string, because neither statement did anything '
Messagebox.Show(MyString)

In entrambi i casi, non sembra disturbare NET che la dichiarazione ha bisogno di un obiettivo di assegnare il risultato a, e non dare uno. C'è una ragione per cui l'IDE / compilatore non mi avvisa di questo effetto, o che un'eccezione "StatementDoesntDoAnything" Non si butta? Dal momento che il codice è formato in modo tale che non potrà mai cambiare nulla, è chiaramente mis-digitato.

Answer 1

Può essere difficile dire che ignorare il valore di ritorno non è destinato, come alcune funzioni fare un po 'effetto collaterale e restituire un valore.

Funzioni che "semplicemente" valori di ritorno dovrebbero essere contrassegnati come tali per avere il compilatore li controllare, e che proprio non è stata una priorità o giudicati di avere abbastanza ritorno sugli investimenti (ovviamente, altrimenti avrei fatto esso:.)

Answer 2

Sì, sarebbe bello se i metodi che non hanno effetti collaterali potrebbero essere contrassegnati con un qualche tipo di [NoSideEffectsAttribute ()] in modo che strumenti come i compilatori possono mettere in guardia, ma al momento nulla di simile mi è noto.

Ma si potrebbe provare FxCop, è possibile individuare un sacco di errori di programmazione sottili su assembly .NET.

Answer 3

Ci sono molti casi in cui i metodi valori che sono opzionalmente gestite dal programmatore ritornano. Non c'è modo per il compilatore a sapere che questo particolare metodo non fa nulla. Si potrebbe avere un effetto collaterale e il fatto che si sceglie di fare nulla con il valore di ritorno del metodo deve essere una decisione consapevole da parte vostra.

Se il compilatore sceglie di avvertirvi di ogni istanza che questo è successo allora si otterrà troppi falsi allarmi.

Answer 4

E 'spesso difficile per il compilatore per determinare se le funzioni di "fare qualcosa". A meno che il compilatore fa rigorosi Analisi Inter-procedurale (IPA), non è in grado di determinare se la funzione chiamata ha un effetto collaterale.

IPA è un processo lento, che aumenta in modo significativo i requisiti di memoria compilatori in modo di default maggior parte dei compilatori non eseguono questo.

Answer 5

Questo comportamento è ereditato da C, C ++, ed è stato orioginally fatto in modo che è possibile scegliere se utilizzare o meno il valore di ritorno da una funzione / metodo di ... Quando si scrive una funzione / metodo che fa un sacco di roba e poi restituisce un certo valore, quando si chiama esso, si ha la possibilità di scrivere

variableName = functionName([parameterlist]);  

se si desidera utilizzare il valore returnb in qualcosa, o semplicemente

functionName([parameterlist]);  

se non lo fai.

Per i metodi di funzione che non hanno effetti collaterali (come quelli che hai citato) come avrete notato, questo non ha senso del tutto, ma cambiare per nuovi linguaggi sarebbe in contrasto con la lunga storia di molte molte altre lingue che sono conformi a questo standard ...

Answer 6

Non sono sicuro di aver ancora un'altra parola chiave per forzare o meno il valore di ritorno per essere messo in una variabile sarebbe una buona idea per vari motivi

1) Supponiamo che si aggiunge una parola chiave quando il valore di ritorno è optinal (da qui insinuare solito è obbligatorio) causerebbe un sacco di codice per fermare la compilazione o tonnellate emesse di avvertimento

2) Si supponga di fare il contrario, l'aggiunta di una parola chiave quando il valore di ritorno è costretto, alcune persone avrebbero semplicemente utilizzare variabili dummy per memorizzarli e continuare a utilizzare il modo ther abituarsi.

3) Non credo che un sacco di gente sarebbe in realtà prendere il tempo per riflettere se il valore di ritorno è facoltativo o meno. In alcuni casi, ho avuto modo di ammettere che è dato, ma non sempre.

Answer 7

Si consideri il metodo di Dictionary<TKey, TValue>.TryGetValue(TKey key, out TValue value): controlla se la chiave è nel dizionario, e se lo è, mette il valore nel parametro out. Il valore di ritorno è un bool che indica se l'operazione ha avuto successo. A volte vi preoccupate; a volte non lo fanno. Penso che questo sia un approccio piuttosto accettato per metodi come questo; se il compilatore ti ha costretto ad assegnare il valore restituito a una variabile, la gente avrebbe un sacco di codice come questo:

int someValue = 0;
bool discard = IntDictionary.TryGetValue("key", out someValue);

// I don't even care if discard is true or false;
// someValue will be 0 if it wasn't in IntDictionary

Answer 8

  

Sono stato morso un paio di volte da

di saltare alle conclusioni, non per

  

dichiarazioni in VB.NET ... che ... non in realtà non fare nulla

, ma che sono in realtà molto ben documentato.