C# Syntax static class, makes static members redundant?

Question

Note: This is the first time asking a question about a general curiosity regarding syntax. Because of this I might not be using the correct terminology to describe my question, which may mean its already been answered, and I can't find it because I'm unaware of what terms to use in the search. If that is the case, please post comments so I can edit and refine the question to meet the standard expected by stack overflow. Thank you.

Now the question. I've been using the static keyword a lot recently because I have members I need to access from anywhere without an instance. However its becoming increasingly tedious to declare every member and method static, when the class its self is already static. Since if you declare a class static, it means you can't create an instance of that class (that's my current understanding).

public static class Foo {}

Why does every member have to also be declared static.

public static class Foo 
{
    public static int X;
    public static int Y;
}

I would have thought that since the class, foo in this case, is declared to be static, all its members would automatically be static, and you no longer need to declare each member as static.

Obviously you can't do that, you have to declare every subsequent member static. However this feels counter intuitive and redundant to me.

Whats the reason for this?

Aside from your primary question, this - *I've been using the static keyword a lot recently because I have members I need to access from anywhere without an instance* - is concerning. Sounds like potential overuse of the Singleton (anti)-pattern. — Yuck, Aug 07 '14 at 02:06
I though as much. I have classes that act as managers that hold information that the entire program needs access to. There is ever only going to be one instance of it. For these classes static is really useful. However I've been suspecting that it may lead to bad practice eventually. — Qdot543, Aug 07 '14 at 02:09
@Yuck Why Singleton an anti pattern? It should not be overused but why do you say it's an anti pattern? — DanKodi, Aug 07 '14 at 02:09
@DanKodi Here's a pretty good Q&A as well as related commentary regarding Singleton, static classes, etc: http://stackoverflow.com/questions/519520/difference-between-static-class-and-singleton-pattern In short, reliance on global state is a bad thing. — Yuck, Aug 07 '14 at 02:12
@Qdot543 Without seeing examples of what you're describing it sounds like you might be re-implementing `ConfigurationManager` and/or AppSettings. How are you currently using that? — Yuck, Aug 07 '14 at 02:16
Maybe I'm picking on the wrong thing here -- but in the .NET world we capitalize the names of classes and properties to help keep consistency with the CLR and other libraries. Here's Microsoft's official naming conventions: http://msdn.microsoft.com/en-us/library/ms229043(v=vs.110).aspx — Warren Rumak, Aug 07 '14 at 02:17
@Yuck I've haven't actually known about `ConfigurationManager` before. Right now I'm working with C# in Unity and before I used c# for Xna. My "Managers" are usually written for more complected systems for which I only need one instance, like a `CollisionManager` that will hold code for accessing the spatial partitioning. I know it may not seem that good practice, but thats how I've done it in the past. — Qdot543, Aug 07 '14 at 02:38

score 4 · Accepted Answer · answered Aug 07 '14 at 02:24

Put simply -- it's for readability. You can look solely at the property definition and know that it's static, without having to look at the class definition.

Your two-line example may make it look unnecessary, but if you have a class with 500, 1000 or more lines of code, you will appreciate the extra clarity when digging through lots of methods, properties and fields.

That's the thing about software development: Never ever worry about a bit of extra typing -- you will read your code many more times than you will write it.

Cool thank you. Its funny that it didn't occur to me that way — Qdot543, Aug 07 '14 at 02:31

score 2 · Answer 2 · answered Aug 07 '14 at 02:09

From what I understand, static on the class is a way to enforce all members are static (remove static from one, and it should give you an error). But yes, there is the requirement of defining the methods static. Technically, you wouldn't need to define static on the class.

You could, as an alternative, define a class, instantiate the class, and store the class reference globally, thus not needing the static definition on each member. The singleton pattern acts very similar in nature to static classes, except you define one common instance shared throughout.

On your second point, I've done that before. However some colleges thought it was bad practice, so I rarely used it anymore, even though I fail to see how it would be bad practice. — Qdot543, Aug 07 '14 at 02:42

score 1 · Answer 3 · answered Aug 07 '14 at 02:34

For consistency - uniformity of meaning. Making a class static doesn't change anything about the class; all it does is forbid the declaration of instance members. The class itself is neither instance nor static. It would be more concise if static on a class implied all members static, but one could argue that doing so would introduce a variable interpretation for a member declaration where not declared static. As it is, members are instance unless the static modifier is used.

C# Syntax static class, makes static members redundant?

3 Answers3