A singleton is clearly better than a global because it's wrapped up in a neat little class and you get the benefits that classes get. Because that allows for more flexibility and organization than a loose global variable. Yes, they have the same scope, but one adds more benefits than the other, does it not?
No, it doesn't. The one and only thing you get out of a singleton that you don't get out of any other global (class) is the enforced restriction that there may only be a single instance, and this is an additional limitation that simply isn't necessary in the majority of cases. If you have a global variable or function and you want to wrap it in a class to provide encapsulation, validate changes, or whatever then by all means put it in a class, but it simply doesn't need to be a singleton, and unless you actually need the highlander rule ("there shall only be one!") you're not gaining any additional benefits from choosing a singleton instead of a regular class.
You obviously understand that globals can potentially cause problems, so the suggestion that a singleton -- which is still global and therefore still susceptible to all the same problems -- is better doesn't make sense. The benefits you listed aren't the benefits of a singleton, they're the benefits of a well designed class which probably doesn't need to be restricted to a single instance in most cases. Singletons increase coupling and make your code less flexible by discouraging re-use. Wrap your variables or functions in a class if you want to -- but why make it a singleton if it isn't an error for there to be more than one?
A singleton IS a global, so you're breaking your own rule of "never use a global" every time you create one.
If you have a genuine need for a singleton then by all means use one. If you're happy to use them in your private code-bases and you aren't experiencing problems then by all means continue to use one. But if you're going to suggest to a less experienced programmer that a singleton is a suitable replacement for a global when it imposes a restriction that isn't usually relevant and leaves the data global an alternative point of view needs to be provided.
...and in the interest of staying on topic, I think the more general case of the point I've been trying to make is:
- Whenever possible, choose the most suitable tool (whether that be a language construct, a language itself, a piece of software, etc.) for the task you are trying to accomplish. Learn the tools that are available to you and their intended purposes so that you don't need to try to use a screwdriver to hammer in a nail.
//EDIT: I just wanted to specifically respond to the following in addition to the above:
I don't get belittling the benefits of what a class offers and clearly " just because it's wrapped up in a fancy class" is belittling what a class offers in it's tone.
I'm not belittling what a class offers at all, I'm belittling what a singleton offers. Singleton is a specific design pattern with additional constraints above-and-beyond those normally imposed by any other class, and to suggest it be applied as a blanket solution to a problem it doesn't actually solve -- that is, trying to avoid the potential pitfalls of globals by using a specific type that is still global -- just doesn't strike me as something that should be in a discussion of "good habits". Use a singleton if you think it's actually the appropriate thing, but if all you need are the benefits of a class then just use a regular class rather than a singleton.
The tone you're picking up on is directed specifically at the mis-application of a singleton, not at the use of classes in general, and certainly not at you personally -- we're all trying to provide helpful information, and I simply felt that one of your points amongst an otherwise good post needed correction. A singleton just isn't appropriate as a blanket solution to situations where you feel the need to use a global -- it doesn't change the scope (which is the original problem) and it introduces additional constraints that may or (more likely) may not be necessary.