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.