Plus délicat/trompeuse à la méthode .Net API?

Question

À la lumière de cette question, je pensais que ça serait vraiment bien d'avoir une question similaire à propos de C#/.Net.

Donc, ce qui est le plus délicat ou trompeuse nom de la méthode de l' .Net et/ou de l'API C#?

Answer 1

Système.DateTime.Ajouter(*)

Je pense que tous les DateTime méthodes en commençant par Add sont trompeuses, considérant DateTime est immuable struct et ne peut pas être changé (ces méthodes retournent des valeurs reflétant l'ajout).

Donc:

DateTime.Add
DateTime.AddTicks
DateTime.AddMilliseconds

etc.

J'y serais allé avec:

DateTime.Plus
DateTime.PlusTicks
DateTime.PlusMilliseconds

etc.

Sans doute le même est vrai de certains string méthodes, telles que l' string.Replace; mais je ne sais vraiment pas quoi d'autre vous appelle.

---

Certains ont objecté que, depuis le comportement de l'opérateur d'addition (+) pour les valeurs numériques est intuitive (et ne modifie pas la valeur de l'instance), l' DateTime.Add(*) les méthodes ne sont pas moins intuitive. Voici ma réponse à cette question.

Permettez l'expression de cette opposition:

Vous n'avez pas s'attendre à ce que i + 5 modifie i, alors, pourquoi pensez-vous qu' d.Add(t)est - il différent?

Maintenant, nous allons répéter cette même question, mais avec des mots anglais à la place de code:

Vous ne vous attendez pas que je plusde 5 modifie - je, alors pourquoi voudriez-vous que d ajouter t est-il différent?

Voyez ce que je veux dire?

---

Wow, si vous voulez voir l'une des plus longues commentaire threads jamais sur une SORTE de question (que j'ai vu, de toute façon), il suffit de faire une charge de commentaires pour cette réponse. Apparemment, l'idée que le mot Add suggère la mutabilité est beaucoup plus subjectif que je ne le pensais.

Answer 2

Une réponse: l' IList<T>.IsReadOnly vs IList.IsReadOnly. Le sens n'est pas clair du tout, et il s'avère que ces deux propriétés ont des significations différentes. :)

Le blog que j'ai créé est résumée ici:

Il existe deux types de mises à jour:

1. Une mise à jour qui modifie la valeur d'un élément dans la collection du musée, et de ne pas modifier le nombre d'éléments dans la collection. par exemple, l'indice de setter.
2. Une mise à jour qui modifie le nombre de valeurs dans la collection, mais ne pas modifier les valeurs des éléments dans la collection. par exemple, Ajouter(), Clear(), etc.

Pour IList

La valeur de IsReadOnly est faux si soit le type de mise à jour est autorisé. Il n'est définie sur true si les deux types de les mises à jour ne sont pas autorisés.

mais pour l' IList<T>

[IsReadOnly] devrait être vrai si l' type de mise à jour n'est pas autorisé. Il est seulement la valeur false si les deux types de mises à jour sont autorisés.

Answer 3

Ce n'est pas une méthode, mais protected internal a fait beaucoup de victimes.

Beaucoup de gens (toux la toux), d'abord attendre que cela signifie que uniquement les types dérivés dans l'actuelle assemblée peut accéder à la partie, mais il permet réellement les types dérivés dans toute l'assemblée et de tout type dans l'actuelle assemblée de l'accès du membre.

Eric Lippert explique pourquoi il en est éminemment raisonnable dans son blog ici (merci Brian pour le lien!). C'est juste une honte, c'est ambigu.

Answer 4

Voici un grand classique: le Chemin d'accès.GetInvalidPathChars, qui "est pas garanti pour contenir l'ensemble des caractères qui ne sont pas valides"

Answer 5

Système.Linq.Énumérable.Inverse

L' Reverse méthode d'extension est étrangement nommé, à mon avis. Pourquoi? Parce qu' List<T>.Reverse existe déjà, et il renverse l'ordre de la liste elle-même. L' Reverse méthode d'extension, sur l'autre main, énumère plus de tout IEnumerable<T> vers l'arrière.

Je l'ai appelé, il Backwards, peut-être (ou même Reversed, avec un "d"). Qui n'aurait pas implicite d'effectuer toute modification de la liste. En Plus de cette façon, si je voulais énumérer plus d'un List<T> vers l'arrière que je pourrais appeler:

myList.Backwards()

au lieu de:

((IEnumerable<T>)myList).Reverse()

ou:

myList.AsEnumerable().Reverse()