Taken to task on my static import post…


Darren took me to task on my post on static import.


Despite the fact that he said, “I code in patterns and in english... the syntax of the language is an afterthought!
If you don't at least tolerate those assertions, don't bother reading the rest of the post
..“, I did read the rest of the post.


I'm not sure exactly what Darren means when he says, “syntax is an afterthought“. I do like his two assertions:


a) when coding, nothing is more important than simplicity and readability
b) my test of readability =
"how long would it take someone who spoke english, but has never seen a computer in their life, to understand the code"


I think where we differ is on how we define readability. I agree that something like


Sin(x)


is quicker to parse than


Math.Sin(x)


But is it easier to understand? Well, that really depends on the person reading the code. If they're familiar with the code and Sin is a very descriptive name, then the first one is to be preferred. If they're unfamiliar with the code (either it's not theirs, or it's code they haven't looked for a while) and/or Sin isn't a descriptive name, then I don't think it's as clear cut. If I don't know what Sin does, I need more information. This could be supplied by a IDE if I hover over the method, but it's not obvious just by looking at the code.


Darren makes some other interesting points that you should read, but I'd really like to comment on his last paragraph:


But when it comes down to it, the biggest reason we should be able to directly "use" static classes is choice. If you don't want to use this feature, then DON'T. Having it in the language doesn't affect you in the slightest. I very much DO want the syntax, even though only for two classes. It affects me, because I want to use it - it doesn't affect you, because you don't... so why do you care?


Every feature in the language effects every user of the language. The question is not “do I use the feature“, but “is the feature used in code that I need to understand“? If the second is true - and I think it is true in almost every case, whether it be on multi-team groups, or code that you come across in books or on the net - then you need to understand the feature. It's going to be discussed in every book (well, every *good* book) on the language, and people aren't going to feel comfortable with the feature until they understand it.


Or, to put it another way, “simplicity is also a feature“.


One other question came up in this thread:


Why are static imports bad, but shortcutting namespaces ok?


Because I say so.


Okay, I guess I'll have to do better about that.


Static imports blur together two different things - methods on the current class, and static methods elsewhere in the system. You can't tell one from the other.


For example:


System.Console.WriteLine(...);


and


Console.WriteLine(...);


Are both obviously static method calls. But


WriteLine(...);


is currently a local method call. With static imports, it could either be that or a static method somewhere else.

Comments (10)

  1. Darren Oakey says:

    I’ll first apologize for the tone of my post – I didn’t mean to be quite so… aggressive – I start writing and get carried away! 🙂

    but anyway, when I said "syntax is an afterthought" – what I really meant was the same as McConnell said in CC2 – there’s a difference between programming "in" a language, and "into" a language. When I’m writing a function, I’ll write out what I want to do in comments above, and then the code. Often the comments are longer than the code – but the hard bit is working out what I want to do – writing the comments – the code itself is what you do once you’ve stopped thinking – The comments and structure would be pretty much the same in whatever language I was coding in. Therefore, what I’m wanting in a language (which, despite all my discussions, C# achieves at the moment far better than any other language) is:

    a) the closest (readability wise) map between my actual code and my pseudo-code

    b) the most language protection possible stopping me making a mistake

    I do also understand your point about choice – the fact that putting bad things in the language affects other people using it. I guess what I meant was more like: some people think a) is more readable/maintainable, some people think b) is more readable/maintainable. Unless you can say a) or b) is more correct than the other, then maybe the best thing is to give people the choice. – of course, thinking about it, that philosophy is in direct contradiction with most of the other things I say, but hey – we can’t be consistent all the time, and I just want static imports 🙂

  2. Jeremy Marsch says:

    For what it’s worth, I agree with Eric on static imports. Where I work, we’ve taken it to a whole other extreme: our standards forbid the use of the using statement to alias a namespace. So we would always use System.Math.Syn(). A bit verbose, yes, but we have a whole application development framework cooking, so it’s nice to be able to look at the code and easily distinguish between a System.. class and one of our classes.

  3. damien morton says:

    A bare WriteLine(..) is currently an instance method call, OR a static method call OR a local variable delegate invokation, OR an instance variable delegate invokation OR a static variable delegate invokation.

    Its already ambiguous, and I have yet to strike a problem with it that cant be resolved easily enough.

  4. Mitch Denny says:

    Hi Eric,

    This has been an interesting thread to read. On the subject of static imports I would generally frown on their use – the same way that I frown on the use of namespace aliasing. But I have to admit that with the release of VSTS into VS2005B1 a few compelling scenarios have actually popped up.

    The one that springs to mind is re-using NUnit test harnesses in VSTS – enabled simply by aliasing a number of the attribute classes.

    I can imagine (but I haven’t tried this) that static imports could assist in automated conversion of C code to Java where the parser would go and find any unrecognised tokens and allow the developer to point to their implementations in some kind of IDE.

    Obviously there would be more to the automated conversion process than this but its what springs to mind.

    Please don’t add this feature to C# 🙂

  5. Some thoughts on static imports and other stuff…

  6. Sumeet Kumar says:

    In VB, hovering the mouse pointer over e.g. "Syn(x)" immediately shows the source of the statement, easily clarifying any doubts as to what it represents.

    And preceding a static method (e.g. WriteLine) with "Console.WriteLine" doesnt really help that much surely as it still be a method call on instance variable Console or a call on Property Console.

    So then we end up always using the namspace and full path to a static method "System.Console.WriteLine" which then has the side effect of making most of the code scroll out of view on the right side.

    I do hope the VB team does not listen to complaints and remove static imports from the language – I like them and find them very useful for the record.

    And if an organisation doesn’t like them, surely they can ban their usage in coding guidelines.

    One way of distinguishing custom static method calls from those to BCL methods is to prefix all static custom method names with a origanisation prefix. I know this has been depreciated in dotnet, but it really works very well in practice.

    Of course C# programmers are the macho guys who like to do it the hard way and they probably wouldn’t appreciate fearures that save time and effort anyway. (Just kidding)

  7. Joe Cheng says:

    :: WriteLine(…);

    is currently a local method call. With static imports, it could either be that or a static method somewhere else. ::

    It could also be defined somewhere in the base class hierarchy–which IMO is at least as difficult to hunt down as a static import, and so are methods defined in partial classes.

    Static import is not much different than implementation inheritance without (external) interface inheritance and without per-object state. I personally don’t understand why any OO programmer would object.

  8. MBA says:

    Helpful For MBA Fans.

Skip to main content