14 replies to this topic

[Illishar]

Very nice documentation btw. Code's not bad either, but you might wanna consider removing the "static" keywords. (Not that important really, but your documentation is so nice, so ...) "static" functions are mostly meant for "helper" functions and functions without side effects. Eg. like the System.Math.

[CW2]

Code's not bad either, but you might wanna consider removing the "static" keywords.

The author needs to use 'static' class members, because they are referenced from within static Main()

[Illishar]

I guess we could give a hint on how to remove the statics. This is *the* .NET way:

...
public static void Main()
{
	//create an "instance" of your program and you won't be needing the statics
	Program app = new Program();
	app.RunYourOwnStartFunction();
}
...

[bill.french]

"static" functions are mostly meant for "helper" functions and functions without side effects.
...
This is *the* .NET way

What are you basing these statements off of? The first doesn't sound quite right to me, but I really don't know and really would like to learn the right (.net) way.

[Illishar]

What are you basing these statements off of? The first doesn't sound quite right to me, but I really don't know and really would like to learn the right (.net) way.

Ever since the beginning of time ... or at least since version 0.9 of .NET, all Microsoft Templates has started out GUI projects with creating an "instance" of your main class. Eg. this is the newest Microsoft template:

    static class Program
    {
        [STAThread]
        static void Main()
        {
            Application.EnableVisualStyles(); /* Didn't exist before .NET 1.1 */
            Application.SetCompatibleTextRenderingDefault(false); /* Didn't exist before .NET 2.0 */
            Application.Run(new MyCustomMainDialog());
        }
    }

Java templates do the same, so it's not that surprising.

The statement about "static" functions beeing stateless and without side effects, is a general rule of proper coding style. Some tools like eg. FxCop, will go through your code and check if it's "nice" code. One of the "nice" rules is that, if you have a function that doesn't uses any global/member data and doesn't have side effects or states, you should consider making it static. FxCop will also tell you so, if I remember correctly. And so it also works the other way around. If your static functions access member data. Eg. statics variables. You might wanna consider making them "not static".
Also if you look around in the Microsoft documentation´, you'll often find statements like "Only our static functions are verified thread safe". This is due to the same "stateless" philosophy.

[bill.french]

Ever since the beginning of time ... or at least since version 0.9 of .NET, all Microsoft Templates has started out GUI projects with creating an "instance" of your main class.
...
The statement about "static" functions beeing stateless and without side effects, is a general rule of proper coding style.

I understand what static is. I'm looking more for literature that supports what sounds a lot like your opinion. Based on what you say, if I have a function that I want only ever want one instance of, unless it's a helper function or without side effects, I should not make it static -- that doesn't quite sit well with my gut, but I really don't know.

Concerning your gui / java example, I (think I) know the templates were that way because they *had* to be, since main has to be static (there can be only one) and you can't call non-static functions or whatever.

"rules of proper coding style" -- where are these rules? I've used static classes to specifically deal with certain state issues.

As I'm writing this, it seems combative, but I really want to understand.

[Corey Kosak]

As I'm writing this, it seems combative, but I really want to understand.

I think I can add my two cents on the philosophical issue here. It often happens that what we think of as today's self-contained program evolves into tomorrow's module-inside-a-larger-program. When this happens, we would like to be able to reuse our classes in the larger program without any rewriting.

If one adopts the thought process that a class is always a part of some larger system, then one is forced to think more carefully about which policy decisions rightfully belong with the class, and which belong to the higher-level environment.

I should also make the distinction between a stateless class (one with no data members) and a stateful one. It is perfectly sensible to use static classes when you have no state at all (the System.Math class is one example). It also may be sensible to have a static immutable class (for example one whose fields are a bunch of string error messages). However, when there is mutable state, it is generally a poor idea to have a static class.

The sin we commit when we make a class static is that we force an "exactly-one" policy for that class, taking away a policy decision that often rightfully belongs to the higher layers of the program. Not only do we take away the ability for the higher-level environment to make many instances of the class, we even take away the ability to make zero instances of the class. The static fields of the class burn up storage for the lifetime of the entire program; the class is constructed at a time the outer environment may not find convenient, and the space used by the class will never be reclaimed. We also force a shared policy rather than a private policy for the usage of that class; that is, with a normal class, when I say "var f=new Foo()", I am typically the only person in the universe that can touch that particular Foo object (unless Foo's constructor does something silly like leak out its 'this' pointer). Other methods can only mess with that object once I start passing around 'f'; there's no other way to get to my object. This is a pretty powerful principle.

A second problem is that static classes tempt us to violate layering. In a complicated system we may have several levels of abstraction; objects pass requests down to objects in lower layers, and return results back up to higher layers. We generally don't want low-level objects calling methods in high-level layers. When programming with static classes, this is all too easy to do, because anybody can call anybody. However, when programming with objects, you can only call a method on an object if you have a reference to it; without that reference, the object is inaccessible to you. This encourages a style of programming where each layer is given only the information that it needs, which is a powerful way of managing complexity in a large program.

There are a few legitimate cases where static classes ought to be used. Thread.CurrentThread and AppDomain.CurrentDomain are two static methods which are quite reasonable, because they refer to concepts that apply to the whole program.

[Illishar]

"rules of proper coding style" -- where are these rules?

The location is not absolute. FxCop as I mentioned contains a huge collection of these "proper" rules. But they originate from various datalogic publications. Books like "Code Complete" are dedicated to this subject. But no respectable programming book, can avoid imposing a subset of these rules (way of thinking) to their readers.
The Pragmatic Programmer should also be worth reading and dedicated to this subject. (I haven't read it though.)
Also the "proper" rules can differ from each language. Eg. the Eiffel language is entirely based upon "good code practise" and forces the programmer into certain naming schemes and code styles.

[CW2]

FxCop as I mentioned contains a huge collection of these "proper" rules. But they originate from various datalogic publications.

Slightly off-topic: FxCop rules do not originate from various publications, they were created by Brad Abrams, Krzysztof Cwalina, Michael Fanning and contributors (they were actually honored with Chairman's Award for Engineering Excellence for it). Brad Abrams and Krzysztof Cwalina also have published Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, which I consider the best book available on the subject, it is also partially available on MSDN under Design Guidelines for Developing Class Libraries.

[bill.french]

Very cool, thank you all -- sorry to hijack. I wish this were a separate thread!

[Chris Walker]

Very cool, thank you all -- sorry to hijack. I wish this were a separate thread!

Done

[bill.french]

Cool, thanks, Chris. This is somewhat related: is there a "cheat sheet" anyone likes on styling code? Stuff like when to use camel case, lower case, etc, for methods, properties, classes, etc? ... and also, what's the current philosophy on namespaces?

[entropi]

The link to "Designing for Class Libraries" on msdn above is a great starting point. For naming in particular, see the subsection: http://msdn.microsof...y/ms229002.aspx We used this as the starting point influence for our own internal coding guidelines.

[Ravenheart]

Although its better to use instances on the full framework, this is MICRO Framework so every little bit of memory saved is worth having static

[Illishar]

Although its better to use instances on the full framework, this is MICRO Framework so every little bit of memory saved is worth having static

As Corey points out, creating static classes will also take away the ability to make *zero* instances. (Not the best feature in low memory environments.)