44

I know there exists already a post, describing nearly the same, but I think mine is a bit different.

What I would like to know is how you organize your extension methods in terms of assigning the namespace. Currently - for the extension methods in our framework - I use the following namespace pattern

  • MyCompany.Web.Utils

and inside I have the extension method classes. This is fine for me with the disadvantage that the extenders are not immediately visible to our software developers. Consider the case where I have a StringExtender class which provides a quite handy extension method "In" that extends the String object. Having the extension method withing the above mentioned namespace, our programmers won't see the extension method unless they explicitly include its namespace. Instead, if I would put the extension method in the System namespace, everyone would immediately see it, but I've read that this is bad practice.

So my question is how you do promote your extension methods s.t. they are used by your developers.

Community
  • 1
  • 1
Juri
  • 32,424
  • 20
  • 102
  • 136

10 Answers10

44

We put them all in their own namespace Company.Common.Extensions. That way, if you have any of our extension methods, you have them all. Plus, at least at my shop, we don't have to worry about our developers not knowing about extension methods. I have the opposite worry, extension method overload! :)

JP Alioto
  • 44,864
  • 6
  • 88
  • 112
  • 2
    (+1) I agree, we use a namingconvention where we add .extensions at the end. – Johan Leino Aug 04 '09 at 08:20
  • That's basically what I'm doing already. So I guess it is the best way to continue like that. Thx – Juri Aug 04 '09 at 08:33
  • +1 about extension overload but at least you have a common namespace, so discovery of whats available is very easy. – Ralph Willgoss May 14 '10 at 00:28
  • I was afraid this wouldnt work if you had multiple projects in the same solution because each solution would need its own namespace but that's not true. Each day project could share the same namespace for the extension methods. – sparebytes Feb 27 '14 at 17:19
10

The problem here is not the naming of the namespace, it's the lack of documentation and education of your developers.

Put them in whatever namespace makes sense, write a wiki article documenting all your extension methods, then send an email to your developers with a link to the wiki article.

Winston Smith
  • 21,585
  • 10
  • 60
  • 75
  • Yes that was my other option. Lack of communication is often an issue in software development teams. We are already in the process of setting up a wiki, but it is often quite difficult, being under time pressure and not getting supported on this kind of activities by the management. I guess people know what I'm talking about. – Juri Aug 04 '09 at 08:32
  • 3
    I feel your pain. Sometimes I find it's better to go ahead and do these things, get people using them and THEN tell the management :) – Winston Smith Aug 04 '09 at 08:36
  • 3
    I don't work on this project anymore and don't have access to the codebase or the wiki. Please could you stop sending me these emails? – jwg Apr 02 '13 at 10:53
7

This is not a namespace problem it is a communication problem.

If these methods are useful you need to communicate this to the developers and, conversely, act on the feedback from them (with appropriate levels of judgement).

Placing anything into the System namespace is a recipe for disaster and confusion later. The only times you ever want to do this is to 'back port' functionality into older frameworks and then you probably shouldn't do it yourself but should use something like LinqBridge to do it.

Be wary of the desire to throw all extensions into one namespace unless they really are widely useful together. Some developers may find the wood lost for the trees if they are bombarded with everything and the kitchen sink via intellisense.

Keeping the namespace the company name is sensible in general to avoid confusion.

ShuggyCoUk
  • 36,004
  • 6
  • 77
  • 101
  • "Be wary of the desire to throw all extensions into one namespace unless they really are widely useful together." We have a quite limited number of extension methods and are also trying to keep them small. So this shouldn't pose a problem. – Juri Aug 04 '09 at 09:09
3

@Juri- If you think about it this is the same problem as developers knowing that class X exists in the .NET framework. Communication is key that all team members use the right classes, be they extension methods or some other helper.

As JP has stated, I often see extension methods in some kind of subfolder called Extensions. Hopefully when you state you use my.company.web.utils the namespace is actually Pascal cased?

Even if you put them in a good place there is no 100% guarantee that other developers will use them.

RichardOD
  • 28,883
  • 9
  • 61
  • 81
  • yes, the name is pascal cased...didn't pay attention on that when posting it here :) – Juri Aug 04 '09 at 08:32
3

Presuming you use Visual Studio, one way would be to create a custom Class template (or modify the default one) so that whenever a developer creates a new class file it automatically has a using statement with your namespace(s). See Customize Visual Studio 2005 Templates for Coding Productivity.

Dan Diplo
  • 25,076
  • 4
  • 67
  • 89
2

Yes,i think put the Extension methods in own company namespce is best practices. put it in System namespace is a lazy operation

Dudu
  • 1,184
  • 1
  • 10
  • 26
  • Putting *anything* in System or other common-anywhere namespace is usually a Poor Decision. Carve off your own namespace (company, project, library, whatever) and use it. Such proper namespace selection is itself a form of code documentation. Further use of a sub-'Extensions' namespace simplifies future work. – user2864740 Dec 29 '20 at 23:45
2

I'm dumb, lazy and minimalistic, so I put them at the same namespace as the type they extend. In this way there is no need for extra using statements, documentation or emailing about them (Winston).

Jorge Picco
  • 179
  • 2
  • 4
  • This is not "lazy" because it makes for *future work*. It is, however, "dumb" as it makes code harder to maintain for the sake 'saving' one line (and a perhaps a directory). This is especially true for any public extensions that begin to pollute external code usages. ["Laziness: The quality that makes you go to great effort to _reduce overall energy expenditure_ .. {and it makes you avoid meaningless shortcuts that make it needlessly less-lazy to maintain code.}"](http://threevirtues.com/). – user2864740 Dec 29 '20 at 23:37
2

I like the way ReSharper solves this problem.

ReSharper discovers any available extension methods, even without the corresponding usings. In case the using is not present, Intellisense also shows the namespace where the extension resides, making clear where the extension comes from and indicating that selecting it will add the using. (Example below.)

Naturally, only namespaces reachable by the current project, i.e. directly or indirectly referenced, are included.

Here is an example of what Intellisense might show if there are two extension methods. The first one comes from a namespace that we have already included. The second comes from a namespace that we have not (yet) included.

  • AddMvc
  • AddEntityFrameworkSqlServer (Microsoft.Extensions.DependencyInjection)
Timo
  • 7,992
  • 4
  • 49
  • 67
0

You can achieve what you want by putting extension methods in the global namespace. That's what I do and they're then available without needing any using statements.

markshep
  • 728
  • 7
  • 17
  • Terrible future-complication-inducing strategy for any non-trivial code, especially if these extensions are public. Suddenly one will move to a different project, or include a different set of assemblies and random extension methods like `string#IsEmpty(this string str)` will 'inexplicably' appear or disappear. – user2864740 Dec 29 '20 at 23:48
0

We put everything into the same Namespace and Class, however we use partial classes to keep them organized.

For example:

ExtensionMethods-String.cs

ExtensionMethods-DataObject.cs

ExtensionMethods-Debug.cs

...etc all have partial classes...

makerofthings7
  • 60,103
  • 53
  • 215
  • 448
  • 2
    What are the advantages to using partial classes for extension methods? I've seen many people drop the extension methods into a .Extensions namespace and name the classes and files after the class they extend: StringExtension.cs and public static class StringExtensions { }. – CodeMonkeyKing Sep 21 '11 at 16:41
  • @CodeMonkeyKing - Some extension methods are forgotten about. When we work with a given app we add the Extension based on logical functionality, which often doesn't align with the layout of .NET classes. Though I like your approach too – makerofthings7 Sep 21 '11 at 20:20