Extension Methods Coding Convention

7 באוקטובר 2009

10 תגובות

Hey there. Me again. That annoying overexcitable programmer. An I sill LOVE Extension methods.

For the past couple of months I’ve experimented with a convention of placing the static class which declares an extension method in the same namespace as the extended type. I didn’t like having to look for extension methods when I wanted to use them (and even Resharpers “Add using” was less than perfect with extension methods). The fact is – if you have an extension – you need to be able to access it with ease. And what’s easier than always having it in Intellisense, just like any other method?

I’ve bounced this idea off my Israel Alt.Net peers, and Amir has noted that this is not future-proof, because someone could add a similarly-named method to the type, and on the next re-compile – invocations will go to it. If the methods would have been declared at another NS – at least I would have gotten a “redundant Using statement” warning from Resharper, and try to find out why.

1) What’s the deal with this lenient compiler? Why is this legal? Throw some compilation errors my way!

2) He’s right.


So I’ve come up with a naming standard that all extension methods will end with an X: the classic “string.IsNullOrEmpty(stringInstance)” will be “stringInstance.IsNullOrEmptyX()”.

This will solve the possible future naming conflict, allow me to declare extension methods in the same NS, and still wouldn’t really bother me when typing the methods name (since it is just a suffix).

I said I will try it out for a while and then decide.


A while passed and I like it.


The reflex-comment about “Hungarian notations are evil” bounces right off me. I think in this case – the fact that I know that some method is an extension does actually help me. Reading code (without an accessible F12 key) could be confusing if you see a method that “you don’t remember ever seeing before on that type”.

One exception to the rule could be extension methods for System.Object. I would not add those extension methods under System, because then they would affect everything. Even if you wrote a perfectly useful method (I had fun with a myObj.GetPrivateField<T>(“_MyField”) method once) – this would cause too much clutter for everyone else. This is the sort of method I would keep in the standard “YourProject.Infra.Extensions” namespace.

An exception to that exception is, of course, if you have a limited scope to begin with – this would not clutter anything: say you have (borrowed from SpecUnit) and assertion method like “myObj.ShouldNotBeNull()” – you could still declare it under System (in your tests project), because it will only be seen in the tests project, where it’s logical to have it everywhere.

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

10 תגובות

  1. Avi Pinto7 באוקטובר 2009 ב 19:51

    overexcitable indeed 😉
    Your solution might only postpone the problem, since other developers, that will read this post and decide to follow your convention, will also call the function
    IsNullOrEmptyX …

    You can always make it internal if it is relevant only for your scope

  2. Ariel7 באוקטובר 2009 ב 20:35


    Using it is not a bad thing. Just like I would like developers to use any Infra class I write – I'd like them to use (or just know about) my extension method.
    Discoverability is the point.

  3. Avi Pinto7 באוקטובר 2009 ב 20:56

    If you want to also expose your extension methods then you can put it under the main namespace of the component – when using the component, the developers will add it's namespace – which will expose all the goodies

  4. Yair Cohen8 באוקטובר 2009 ב 9:40

    Totally agree with Avi, I think it is not the wrong solution, but the wrong problem… maybe laziness? I just put them in the graceful namespace of my company (Mobideo) and by the naming conventions, almost all our code is or under Mobideo. or using it and it is discoverable. I agree that it has some hassles when intellisense does not recoginze it… but this is the rare case.

  5. Ariel8 באוקטובר 2009 ב 10:59

    Avi –
    Well, that was the point of this post. The initial promise was to put extension methods in the namespace of the extended type…

    Yair –
    "The wrong problem" does not compile. 🙂
    I have a problem which is the discoverability of my extension methods.
    A solution to that problem could be placing them in the root namespace of your project, but let's face it – it's a hack. They don't really "belong" there. And if you're willing to put them in a namespace other than your run-of-the-mill "MyProj.Infra.Extensions" namespace – why not the extended types namespace?

  6. Avi Pinto8 באוקטובר 2009 ב 13:30

    Ariel –
    I know it was the point of this post, but it might be a wrong point 🙂
    If you put them at the the extended types namespace you go back to the original problem that Amir raised(unless they are internal, which is not what you wanted in the first place).
    and putting it under a separate namespace MyProj.Infra.Extensions only hides them.

  7. Ariel8 באוקטובר 2009 ב 15:57

    But now that I've suffixed my method with an X – it's more than probable that no-one will create a method called like that.

    Unless you extend the class Bicycle with the method BMX().

  8. Avi Pinto8 באוקטובר 2009 ב 16:37

    maybe you should put a GUID instead of the mighty X,
    more powerful ain't it?

  9. ToratordDrale25 בפברואר 2011 ב 22:59

    Acemaster53|I saw thisп»ї LOOOONG before Meekakitty posted hers since I subscribe to both Tessa and Kristina. Meeka s is good but this is way more creative.