Indie-Resource.com

here's mine.

When you are programming in VSTO, Microsoft uses a singleton pattern for the current document. In the case of Excel, it is ThisWorkbook. This singleton object is a great place to stuff information that you want to... oh let's call it what it is... its a great place to abuse the singleton pattern to stuff global variables in a language designed not to let you use globals (because globals are bad, evil, poor programmer form).

So I've got this block of code in the Magicus Occultus Excel to Database exporter.
No, I don't need to worry about thread saftey, which is why I felt safe using the simplicity of a global variable.

I think it is interesting how safety over rides simplicity and causes hours more work even on internal apps with no worries of hacking. To me a program that works works. No matter what methods it uses. Take a internal report system that simply builds reports from a database. Why do I have to worry about public variables again or worry about keep people from hacking it?

Because of the sanctity of the programming temple!

Mostly for your own safety really. Globals are bad mostly because it`s impossible to keep track of it. So, you have no way of knowing where or when a certain value is set in your global. Mostly, because, well.. they`re global! It produces unexpected behaviour.

The same goes for public variables, it produces unexpected behaviour. You have no control when or where a given public var is set. This in itself is not really dangerous, I mean, we are all lazy programmers so we use it from time to time regardless, but only on our private projects, right?

In a production environment ( even inhouse apps!) we should always properly encapsulate our code, for a number of reasons. If your firm is hiring a new programmer, he will have a hard time understanding the code and will not be able to fully understand how to code runs and second ( and this has to do with unexpected behaviour again ) a program may run perfectly fine for a while until a certain point at which it will generate the most random number of errors/exceptions and you have no clue where to look for the bug.

So I`m weary of using singletons, static classes and public variables, as a result, I don`t use them often. Sure, singletons have their purpose, as well as static classes I suppose ( can`t think of one right now) but only use them with extreme caution.

I do not see that mystery around public variables. I know exactly where they are, their value, and what's going on as much as a private variable. I can understand the mis use in a large production environment but not smaller programs with a single purpose.

You`re right, they don`t appear to be harmful, especially in smaller projects where only a couple of programmers are working together. But the harmful aspect is it`s publicity. It can be changed everywhere a ref to the object exists and you cannot document the changes. If you have a setter for it, you can log messages inside the setter for debugging purposes, that`s impossible if you access the public var directly since you don`t know where the call came from.

In any case, as states in my previous post; it creates unexpected behaviour, any and all code that has UB is considered bad practise. Not bad perse.