Allow using up to the object level.

Darren sent me a few questions. Normally, I'd put these in the C# FAQ, but I've decided to answer them here for now. They may migrate to the FAQ in time.


*** allow "using" up to the object level


I use VB sometimes, and one of the things I really love about it is that if I create a static class (say CommonFunctions)  I can import SMB.Common.CommonFunctions.  All static functions are now part of just my standard namespace.   I like it!  Object purists may have collective apoplexy, but I'd prefer to remain agnostic and believe that we shouldn't have to qualify absolutely everything we do.  Some functions really do belong in the global namespace (and all languages have some) - and it would be really nice as a developer to be able to make our own.  It's there in VB - can we have it in C#?  Please? 🙂


I think it's unlikely that we will do this. I understand the desire to be able to do this, but one of our major goals is to keep the language readable. Features like this and C++'s macros mean that to read code, you don't just have to understand the base language, you also have to understand all the additions that have been added by the author of the current project.


So, yes, it is true that writing Math.Sin() is longer than just writing Sin(), but it's also much clearer to any reader of the code.

Comments (16)

  1. Joe White says:


    I have a Delphi background, and while it’s sometimes kind of nice that Delphi allows global functions, it’s more often tedious — since I have to hunt through a dozen different source files to find the one that actually implements that procedure. I’ve come to appreciate the C# way, both of making you scope methods to a class, and of giving you an error if you import two namespaces with the same class name.

  2. J. Daniel Smith says:

    And can’t you already write something like

    using SMB.Common.CommonFunctions = Globals;


    at least that’s shorter than SMB.Common.CommonFunctions.Func1();

  3. I just recovered from a small bout of apoplexy. Now that I have my wits about me, I must say that I appreciate that C# will not support this. It’s a great idea, and the feature is pretty darn nice to have, but while I’m taking the extra keystrokes to ensure that my code is of the correct case, I don’t mind also qualifying the precise purpose of my code.

    I think it’s good that we can do this in VB.NET, though. I probably won’t because it triggers my acute apoplexy syndrome, but it’s nice to know I can when I want to. All I have to do is change languages.

  4. Corrado Cavalli says:

    Totally agree wit Eric,

    I prefer a clearer statement vs less keystrokes (and Whidbey intellisense has been improved a lot on C#…)

  5. John says:

    In my own code I would never do something like this:

    using SMB.Common.CommonFunctions = Globals;

    I think it just leads to unnecessary confusion. Why give the same thing two names?

    I also always qualify my namespace, so if I’m calling a public static method I use the name of the class (even if I’m calling from within that class), and I always use ‘this’ infront of instance methods.

    Doing it this way also means that IntelliSense pops up without needing to press CTRL-SPACE (which I find slows me down) and removes any ambiguity.


  6. John Rusk says:

    Coming from a Delphi background, one thing I do miss in C# is the readability of mathematical expressions. E.g.

    a = Round(Sin(y));

    is easier to read that

    a = Math.Round(Math.Sin(y));

    With the first one, you can read it more "fluently" in your head.

    So, from a readability point of view, I like the suggested feature. On the other hand, apart from the Math class, I can’t think of may cases where I would use it.


  7. John Rusk says:

    "…may cases where I would use it."

    Make that "… MANY cases …"


  8. Jason G says:

    No, make that "English.MANY". We still qualify our constants around here….

  9. Darren Oakey says:

    I’m just really think program readability is a big factor – Believe it or not, the reason I programmed in VB 6 over Delphi, even though I LOVE pascal, was purely this: VB didn’t require brackets on function calls – so you could make more readable code.

    Let me give you an example:

    A:[OLD VB]

    public sub PopulateTheScreenFrom( theListOfEmployees as EmployeeCollection )

    EnsureThatWeAreNotMissing theListOfEmployees

    for each employeeToAdd as employee in theListOfEmployees

    AddToTheScreen employeeToAdd

    end sub

    B:[C# allowing us to reference CommonFunctions]

    public void PopulateTheSCreenFrom( EmployeeCollection theListOfEmployees)


    EnsureNotMissing( theListOfEmployees );

    foreach Employee employeeToAdd in theListOfEmployees

    AddToTheScreen( employeeToAdd );


    C:[C# as it is]

    public void PopulateTheSCreenFrom( EmployeeCollection theListOfEmployees)


    CommonFunctions.EnsureNotMissing( theListOfEmployees );

    foreach Employee employeeToAdd in theListOfEmployees

    AddToTheScreen( employeeToAdd );


    Now, I would never use this for non-structural classes, but for those common functions that are essentially part of your "Framework" – I think it’s much cleaner. I think any person would find A easier to understand than B, easier to understand than C – and isn’t that what we are going for? If you want to know where something is defined you can right click and ask, but to me the key thing is to make our code as clean and as human-readable as possible…

  10. Daniel O'Connell says:

    I don’t think so…

    Frankly, in A, I don’t know if you are defining a variable or making a call. If I didn’t know VB syntax I couldn’t figure that out, so claiming anyone could do it is a bad idea; someone who knows another language and no basic is going to be confused. Someone who knows no computer language is more likely to understand it than someone who only knows C based languages.

    Personaly, B suggests to me that EnsureNotMissing is a local instance method…that isn’t particular readable either.

    VB’s lack of bracketing around method calls is probably my #2 reason for disliking that language.

  11. Jeremy Marsch says:

    For my vote (even as a former Delphi developer), I’m very glad that C# is the way it is.

    In fact, in the shop that I’m in now, our code standards prohibit use of the using clause at all (prohibit using for namespace shortcuts, not using{} for disposal).

    It makes the code lines a little bit longer, but once we started doing it, the code became remarkably clear, and now it looks very strange, and even a little beginnerish to me when I see code that uses the using shortcuts.

    Another readability item is the "this" operator. We started always using the optional "this" when referencing an instance member. At first, it looked very strange, but now now that I’m used to it it’s great — an explicit label indicating that you are referencing an instance member.

    The full naming doesn’t seem like such a big deal when you are initially writing the code, but when you are updating it, or modifying some else’s code, you get a very clear picture of what is going on.

    We kind of picked this off in the same spirit as the "ref" keyword for parameters in C# — C# makes you mark a parameter as "ref" in both the method definition and the method call, so that it’s explicit. We saw that and thought "that’s a really cool idea."

  12. Daniel O'Connell says:

    All I can say is I’m glad I don’t work in your shop. I’d probably have to resign.

  13. Darren Oakey says:

    I have read and agree with a lot of the arguments above (except Jeremy – it’s funny -I’ve written coding standards for several organisations – and always explicity say you MUST use using, you must NOT fully qualify _anything_ – in fact, I’ve written a code checker that (among all our other standards) is on our current build machine and will deny your integration if you use "this." or have a fully qualified name anywhere except in generated code regions. (different strokes for different folks))

    To me, (and I have fortunately always been in the position of MAKING the standards, <grin>) – the most important thing is code readability. Maybe because the computer world changes so much – I don’t think in my life I’ve ever had two successive contracts using the same language! I want people’s code to look as much as possible like english pseudo-code. I don’t want code that you can show an expert in C# and they can understand it easily. I want code that you can put on a web site and show a team of business analysts and say "these are the business rules we are following". I want code that we can hire a programmer off the street who’s never seen C#, say "here’s your user story, here’s the component you are working on – write a test that looks like this, and then get it working – GO".

    However, my final say on the matter would be – some people don’t like the feature, but some people would want it. If you don’t like it – don’t use it. _ALL_ our code standards are enforced by a checker, so if we don’t want someone to use a feature, we can stop them. (and if you don’t use automated code standards checking, you deserve what you get – remember FXCop is FREE :))

    However, I do think if a number of people do want the feature in the language, it doesn’t drastically alter the shape of the language, and it’s easy to do, then why not add it? Some people are happy, some don’t care.

  14. Daniel O'Connell says:

    That actually brings up an intersting possibilty. For some features like using(for namespaces) vs fully qualified paths, the this keyword prefix, etc, it should be possible, while not the easiet thing to do, to write a parsersemi-compiler that would transform code using one convention into code using the other based on what the compiler sees…it would certainly make surviving in shops where using was forbidden easier if you could pass your code through that. It does however have the problem of trouble with source control, etc.

Skip to main content