Obviously there can't be an instance member on a static class, since that class could never be instantiated. Why do we need to declare members as static?
8 Answers
I get asked questions like this all the time. Basically the question boils down to "when a fact about a declared member can be deduced by the compiler should the explicit declaration of that fact be (1) required, (2) optional, or (3) forbidden?"
There's no one easy answer. Each one has to be taken on a case-by-case basis. Putting "static" on a member of a static class is required. Putting "new" on a hiding, non-overriding method of a derived class is optional. Putting "static" on a const is forbidden.
Briefly considering your scenario, it seems bizarre to make it forbidden. You have a whole class full of methods marked "static". You decide to make the class static and that means you have to remove all the static modifiers? That's weird.
It seems bizarre to make it optional; suppose you have a static class and two methods, one marked static, one not. Since static is not normally the default, it seems natural to think that there is intended to be a difference between them. Making it optional seems to be potentially confusing.
That leaves making it required, as the least bad of the three options.
See http://blogs.msdn.com/b/ericlippert/archive/2010/06/10/don-t-repeat-yourself-consts-are-already-static.aspx for more thoughts on these sorts of problems.
8 Comments
Caspar Kleijne
I see your point but how about e.g private then? Not quite te same, but pretty optional. Or is it optional because it is default?
Eric Lippert
@Caspar: what about "private"? Because it is the default, it's optional. And because the default is the most restrictive, it is harmless to accidentally leave it off; you can't expose more than you intend, only less.
richard
@Eric: I was hoping you would weigh in! Is this what you intended to say: "you have a method marked as static and a method not marked as static" or did you mean this "you have a class marked as static and a method not marked as static"? If the former then I am a bit confused by that statement.
richard
@Eric: So I guess the difference between this decision and the decision you made with constants is that constants can't be anything but static, so it makes sense to make it illegal since it's inherent in the type. Whereas with other class members (methods, properties, etc.), they could be static, or not, and so it's better to make it explicit for readability and to avoid confusion.
richard
@Eric: By the way, thanks for the link to the blog post and the SO question about constants.
|
Because by definition, all of their members must be static. They decided not to give some confusing syntactic sugar.
3 Comments
richard
I know but there is confusing syntactic sugar all throughout the C# language. In fact, they keep adding to it. Why they left this out is beyond me.
soandos
To make it clear that all of those elements are static. It would be pretty confusing not having something declared as static, but it being static. Can't comment on the rest of the language.
dsum
I have to say they make a good decision on explicitly stating member is a static. Think about .NET 4.0 var. It is easy to use, but for inexperience developers it can get confusing because the type wasn't explicit.
I would go one step further and ask: Why does C# have static classes at all? It seems like a weird concept, a class that's not really a class. It's just a container, you can't use it to type any variables, parameters or fields. You also can't use it as a type parameter. And of course, you can never have an instance of such a class.
I'd rather have modules, like in VB.NET and F#. And then, the static modifier would not be necessary to avoid confusion.
Comments
It could be implicit, but also it would complicate code reading and lead to confusions.
Comments
Richard,
Hmmmm... I'd guess that the language designers decided that it would be better to be very, very explicit... to avert any possible confusion when a maintainer, who doesn't know the code, jumps into the middle of a static class, and presumes that they are in a "normal" instance context.
But of course, that's just a guess. Most IDE's help you out there anyway, by adding the static modifier "automagically"... or at least highlighting your mistake at "write time", as apposed to "compile time".
It's a good question... unfortunately not one with a "correct" answer... unless someone can turn up a link from a C#-language-designers blog (or similar) discussing this decision. What I can tell you is: "I'd bet $1,000 that it's no accident."
Cheers. Keith.
13 Comments
corlettk
@Eric, Dude... Got proof of that? I'd like to read the designers thoughts, that's all... Like I said, I'm pretty damn confident that it's NO accident... I just can't "prove" it.
Eric Lippert
Right; you're asking for an opinion from one of the C# language designers, and you've got one. I'm a member of the C# language design committee.
SolutionYogi
corlettk, Eric is part of C# design team (and one who shares lot of details behind the design decisions made by the team) so if he says that it was 'no accident'. That's a proof enough for me. :)
Eric Lippert
@Joan: It's a benevolent dictatorship, though occasionally things do come to a vote. It is certainly beneficial to get ideas from the public, but you know, if we drove the design process strictly by public input, great features like LINQ would never happen. It's not like we got a lot of mail saying "please add query comprehensions based on the sequence monad to C#".
Eric Lippert
@corlettk: no worries! @Joan: we have a group of MVPs and other industry insiders that we consult regularly on those sorts of things, and sometimes if we have a bunch of them in a room we'll do a "straw poll" sort of vote, but of course it is not binding. I'll also occasionally do straw polls on the blog if we need a quick sanity check from the community on whether a feature is confusing or not.
|
Explicit coding makes things maintainable
If I want to copy a method from one class to another, so that code is better organized, then I would have to keep cheking a lot of things all the time, just in case the destination class is or is not static.
By declaring the member as static, you also have a visual indication of what the code is, when you see it.
It is also less confusing. Imagine a class that is static, and inside it has got members marked as static, and others not marked.
I can see lots of reasons, and many other reasons exist.
Comments
One reason I would think it is important to explicitly state it is a static is because in a multi-threaded programming model, these static variables are shared by multiple threads. When doing code review or code analysis, it is much easier to pick up this importance from reading the variable, instead of looking up the class declaration, and determine if the variables are static or non-static. It can get pretty confusing when reading variable during code review if you don't know if the class is static or non-static.
Comments
This is because copy-paste would be more complicated.
If you copy a method from a static class to a non-static class then you would have to add the static keyword.
If you copy a method from a non-static class to a static class you would have to remove the static keyword.
Moving methods around is the primary thing developers do ('I need to refactor this code, it will take a week at least'), and by making it easier Eric and his team allowed us to save hours of work.
static. Similarly, even if you do see the class declaration, there will be no confusion when people mix and match supplying it versus not supplying it.