Pourquoi ne pas les déclarations qui ne font rien jeter une exception (ou avertir le développeur)?

Question

J'ai été mordu à plusieurs reprises par des déclarations dans VB.NET (ne sais pas si cet effet existe en C #) qui semblent être auto-référencement, mais quand ils sont exécutés, ils ne le font pas quoi que ce soit parce qu'ils ont besoin d'une cible et n'est pas fournie. Par exemple:

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)

Dans les deux cas, il ne semble pas déranger .NET que l'instruction a besoin d'une cible d'affecter le résultat, et je ne donne pas un. Y at-il une raison que l'IDE / compilateur ne me prévient pas de cet effet, ou qui ne sont pas jeté une exception « StatementDoesntDoAnything »? Étant donné que le code est formé de telle sorte qu'il ne changera jamais quoi que ce soit, il est clairement mal tapé.

Answer 1

Il peut être difficile de dire qu'ignorer la valeur de retour ne vise pas, comme certaines fonctions font certains effets secondaires et retourner une valeur.

Fonctions qui « simplement » valeurs de retour devraient être marqués comme tels pour lui demander de vérifier le compilateur, et que tout n'a pas été une priorité ou jugée assez retour sur investissement (évidemment, sinon ils auraient fait il:.)

Answer 2

Oui, ce serait bien si les méthodes qui ont pas d'effets secondaires pourraient être marqués par une sorte de [NoSideEffectsAttribute ()] de sorte que des outils tels que des compilateurs peuvent vous mettre en garde, mais à l'heure actuelle pas une telle chose est à ma connaissance.

Mais vous pouvez essayer FxCop, il peut repérer beaucoup d'erreurs de programmation subtiles sur des assemblages .NET.

Answer 3

Il existe de nombreux cas où des méthodes renvoient des valeurs qui sont éventuellement traitées par le programmeur. Il n'y a aucun moyen pour le compilateur de savoir que cette méthode particulière ne fait rien. Il pourrait avoir un effet secondaire et le fait que vous choisissez de ne rien faire avec la valeur de retour de la méthode doit être une décision concious de votre part.

Si le compilateur choisi de vous avertir de tous les cas que cela se produisait alors vous obtiendrez trop de fausses alertes.

Answer 4

Il est souvent difficile pour le compilateur de déterminer si les fonctions « faire quelque chose ». À moins que le compilateur ne href="http://en.wikipedia.org/wiki/Interprocedural_optimization" rigoureux Analyse Inter-procédure (IPA), il ne peut pas déterminer si la fonction appel a un effet secondaire.

IPA est un processus lent qui augmente de manière significative les compilateurs besoins en mémoire donc par défaut la plupart des compilateurs ne fonctionnent pas.

Answer 5

Ce comportement est hérité de C, C ++, et a été orioginally fait que vous pouvez choisir d'utiliser ou non la valeur de retour d'une fonction / méthode ... Lorsque vous écrivez une fonction / méthode qui fait un tas de choses puis retourne une valeur, lorsque vous l'appelez, vous avez la possibilité d'écrire

variableName = functionName([parameterlist]);  

si vous souhaitez utiliser la valeur returnb quelque chose, ou tout simplement

functionName([parameterlist]);  

si vous ne le faites pas.

Pour les méthodes de fonction qui ont pas d'effets secondaires (comme ceux que vous mentionnez) que vous avez noté, cela ne veut pas tout à fait logique, mais changer pour de nouvelles langues irait à l'encontre de la longue histoire de beaucoup d'autres langues qui sont conformes à cette norme ...

Answer 6

Je ne suis pas sûr d'avoir encore un autre mot-clé pour forcer ou non la valeur de retour à mettre en une variable serait une bonne idée pour diverses raisons

1) Supposons que vous ajoutez un mot-clé lorsque la valeur de retour est optinal (donc sous-entendre est généralement obligatoire) causerait beaucoup de code pour arrêter la compilation ou émis des tonnes d'avertissement

2) Supposons que vous faites l'inverse, l'ajout d'un mot-clé lorsque la valeur de retour est forcé, certaines personnes simplement utiliser des variables muettes pour les stocker et continuer à l'utiliser comme ther utilisé pour.

3) Je ne pense pas que beaucoup de gens vraiment prendre le temps de se demander si oui ou non la valeur de retour est facultatif ou non. Dans certains cas, je dois admettre qu'il est donné, mais pas toujours.

Answer 7

Considérez la méthode Dictionary<TKey, TValue>.TryGetValue(TKey key, out TValue value): il vérifie si la clé est dans le dictionnaire, et si elle est, elle met la valeur dans le paramètre out. La valeur de retour est un bool indiquant si l'opération a réussi. Parfois, vous vous souciez; parfois vous ne le faites pas. Je pense que c'est une approche assez acceptée pour des méthodes comme celle-ci; si le compilateur vous a forcé à affecter la valeur de retour à une variable, les gens ont beaucoup de code comme ceci:

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

  

J'ai été mordu deux fois par

sauter à des conclusions, et non par

  

déclarations contenues dans VB.NET ... que ... ne font rien

mais qui sont en fait très bien documenté.