Guidelines for naming C # classes / methods designed to replace existing APIs

A long explanation aside, I have a situation where I need to basically reimplement the .NET framework class in order to extend the behavior in a way that is incompatible with the inheritance or build / delegation strategy. The question is not what I should do, what to do, or recommend, but instead the question of naming / coding.

Is there a paradigm for naming classes and methods that have the same functionality as an existing class or method, as well as the ClassEx / MethodEx convention that exists in C ++?

[edit] I understand that choosing good names is important for this ... I haven't written a line of code yet and instead spend time thinking about what I'm going to do, and this includes finding a clear, descriptive, name, trying to be brief. The problem is that the name I mean is not too short. [/ Edit]

+4
source share
4 answers

Here is what I saw in the .NET Framework itself:

  • Call it a little differently, but do not use any specific suffix. For example, System.TimeZoneInfo was introduced to replace System.TimeZone .

  • Put it in a different namespace. For example, the WPF Button is located in System.Windows instead of System.Windows.Forms .

  • Suffix with number. For example, X509Certificate2 compared to X509Certificate . (This practice was common with COM interfaces, but in .NET it has become obsolete.)

Note that naming TimeZoneInfo is a public Microsoft case that solves this problem with a convective error. See and http://blogs.msdn.com/kathykam/archive/2007/03/28/bye-bye-system-timezone2-hello-system-timezoneinfo.aspx and http://blogs.msdn.com/kcwalina/ archive / 2006/10/06 / TimeZone2Naming.aspx for excellent information.

+5
source

Try to name your classes / methods real value.

For example, if you extend the functionality of Random to create random strings, name the class StringRandom or StringRandomizer, etc.

If you are writing a class with general-purpose extension methods that apply to a specific class / interface, such as IList, name it ListExtensions.

If you write a random.Next method that returns a random number between minValue and maxValue, including maxValue, name the NextIncludingMaxValue method.

If you are writing a queue.Dequeue method that is thread safe, specify if DequeueThreadSafe.

If you write a queue.Dequeue method that blocks until another thread deceives an element, name it DequeueBlocking.

And so ...

+1
source

C #, for the most part, completely eliminates these situations because of the simplicity with which you can extend the class with new methods without breaking binary compatibility (you can add methods as you wish to the class and not to the interface), as well as using extension methods.

There are several reasons in C # to ever do this, unlike C ++. In C ++, adding a method breaks compatibility, so "Ex" becomes a much more common scenario.

0
source

I give all my methods (and properties) camelCase names: for example, Invalidate is the name of the structure method, and Invalidate is the name of one of my methods.

This (using camelCase names) is unconventional, so some people object to it, but I find it convenient.

There is no such problem with class names (for which I use regular UpperCase), because for class names there are their namespaces to distinguish them from framework classes.

0
source

All Articles