>>>I wonder what the best practice would be when it comes to declare classes (and more importantly methods) static. I have found that in most cases pundits declare non static classes and methods where it would be perfectly workable to have them static.
>>>
>>>The way I see it is that static is easier to test no?
>>
>>http://msdn.microsoft.com/en-us/library/79b3xss3%28v=vs.80%29.aspx
>>Here's what MSDN says.
>>Basically, I use them the way MSDN suggests.
>
>So the wisdom is "when in doubt, refrain from declaring 'm static" right?

Looking at the classes in the .NET Framework which are static should give you a good feel for what makes a good candidate for 'static'

For example, in the 'System' namespace the Console, Math, Buffer, BitConverter, Convert and Tuple classes are all static.

It would feel odd (and unnecessary) to have to instantiate one of those before using e.g.:

Convert c = new Convert();
c.ToBase64String(myBytes[]);

.... which also leaves an object that needs to be cleaned up by the garbage collector :-{