views:

557

answers:

2

What naming conventions are you using for namespaces and sponsor classes? (i.e. the classes that hold extension method definitions)

Is there a standard/recommended .NET Framework naming convention? (the "Framework Design Guidelines, 2nd Edition" book only gives guidance on what namespaces not to use).

+7  A: 

I haven't seen any official recommendations, but I've been organizing my extension classes like [NameSpace].[ClassName]Extensions:

ProjectName.Web.Util.ControlExtensions
ProjectName.Data.Util.CollectionExtensions
jrummell
I do the same and I would add also add that I tend to place any highly specialized static extension method classes into related namespaces to where they would be used so that they won't cloud up intellisense for other developers. So in other words my extension method classes are not necessarily in the same namespace as the class that they extend.
jpierson
+2  A: 

For the Namespace - I would focus on the standard framework guidelines for namespace names. Put the extension methods into a namespace where they will typically be used/associated meaningfully, and avoid having an extra namespace just for this.

For the sponsor class - in this case, it's fairly unimportant. I would try to pick a class name that is meaningful, but there does not seem to be a fixed guideline.

The important thing here, though, is that the sponsor class is never really directly used/seen by the user of your extension methods. As long as the namespace has been included, the extension method is found correctly. I personally use something very similar to jrummell for my extension methods, but Microsoft does not follow this in the Framework (a good example of this is the Enumerable class).

Reed Copsey
Both Reed and jrummell answers are good. I am going to mark this one as "The" answer because it goes into more depth. One note though - sponsor class name DOES matter in .NET languages that don't support extension methods, where classical static method call has to be used.
Milan Gardian