I have moved to naming global singletons with a The* prefix | Hacker News Reader

I have moved to naming global singletons with a The* prefix

twitter.com

56 pointsswalsh48 comments

Giving expressive, meaningful, coherent and readable names to the entities used all the time in programming languages (variables, functions, procedures, classes, methods, etc) is an incredibly challenging task that in general doesn't seem to be acknowledged as such.

Oh I find it easy to give meaningful names, I just find it immensely more difficult to get others to agree with my choice.

I did find when participating on a standards group within our shop that you cannot have any ambiguity when it comes to naming conventions. When there is we end up with some designated to lead and force all decisions to that person, it becomes amazing how many different ways developers can say the same thing.

Successes aren't acknowledged often because we are often dissatisfied with them and they can be bikeshedded. But I'm pretty sure the importance of naming is widely acknowledged.

  "There are only two hard problems in Computer Science:
   cache invalidation and naming things."

   -- Phil Karlton

and off-by-one errors.

There are only two hard problems in Computer Science: cache invalidation, naming things and off-by-one errors.

There are only 10 hard problems in Computer Science.

Nobody expects the cache invalidation!

One person expects the off-by-one error!

Huh? Oh, I think you mean ComputerScience.js

Yup! There are really only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.

I have concluded that singletons should not be used ever for anything. Because practically always there appears a situation when a singleton has to be used as a doubleton or multipleton, and doing such refactoring is a mess. I am not even talking about such things as automated testing, multithreading, self-referencing, the order of initialization, etc.

Agree 1000%. Haven't used once since 2002 since I started using di containers.

Exactly, the "Singleton" pattern should only be used when having two instances of one object will be catastrophic. In all other situations where you only think you want one of a class, dependency injection handles that. A good DI container will even keep track of your pseudo-singleton for you.

Then unit testing becomes feasible again, without having to hack around that Class X is using the "ConnectionManager" to connect to the database behind your back.

I always laughed when people said "yeah, but, why would you ever want two ConnectionManagers? What if you create more than one accidentally! Make it a singleton and that can't happen!"

My reply was along the lines of "when was the last time you accidentally wrote two for loops when you wanted only one? If you don't want more than one ConnectionManagers then don't create more than one"

In my opinion its very rare that you need an object that is both globally accessible and you must not have more than one.

I think that's kind of like the goto keyword rule. For 99% of the situations, its true. You can avoid it. 1% of the time though, its a really clean way to accomplish a specific type of task.

A new feature I was working on a few months ago at my job was held up for two weeks while a developer who wrote some underlying code removed the singleton he wrote and replaced it with a not-singleton. This was so that we could have different versions of a simple C struct datastore for different stored configurations.

Singleton vs. Anti-Singleton is a holy war.

Some (perhaps most) people who use singletons use them inappropriately. That does not imply that there is no situation for which using one would be appropriate.

The pattern is not to blame, but the close coupling, global state, multiple responsibility, and dependency hiding that are enabled by it. They're perfectly fine as resource managers or for immutable references.

Also, premature optimization is an anti-pattern. The advantage of singleton is that it is super easy to set up, and get to working code, then refactor it out immediately afterward.

If removing it does not improve the code, it must belong there, right? That said, it's pretty easy to improve the code by removing it.

Removing a singleton is incredibly costly due to the "close coupling, global state, multiple responsibility, and dependency hiding that are enabled by it".

If I were to compile a top 10 list of terrible refactoring projects I've worked on, ALL of them would be on code that had stalled out due to a "singleton" global variable code-complexity ceiling.

Anti-singleton is a holy war because the people who produce such shockingly crap singleton-riddled code are externalizing enormous and soul-crushing costs onto both customers and future maintainers.

I guess we know which side you're on, then.

I'd caution against inverting the conditional probability of writes singletons given unskilled programmer into probability of unskilled programmer given writes singletons. It's a fallacious operation.

You can't eliminate bad code by eliminating singletons. You can only do it by turning unskilled programmers into skilled programmers. "Don't use singletons" is fine advice for a novice, but it would be better to teach the principles that underlie that advice and use Socratic questioning to make them realize that MOST uses of singleton violate one or more of those principles.

You're right that writing singletons needs expertise because there are a number of (possibly unsolvable) gotchas that you need to know about to even start using singletons.

Take the self-referencing problem: let's say we have a logger singleton (pretty simple, what could possibly go wrong?) And let's say that the logger singleton invokes particular code during its initialization, such as the file I/O code that is also our own and that uses... guess what? a logger! Thus, when the logger class initializes, it will either try to log using an uninitialized object or invoke the initialization recursively depending on whether the singleton is lazy or not. A beginner is normally not aware of this problem when they are writing their singleton class. Another problem is the initialization order: what is initialized first - the logger singleton or the I/O singleton? Turns out, we just have to use lazy initialization. Then the multithreading comes on the scene. So you have to make a thread safe lazy singleton. But that implies additional cost on every call for the singleton.

I don't know... Singletons are a mess.

You can eliminate bad programmers by eliminating those that would use global variables.

We used to use *Manager: AudioManager, StreamingManager, etc.

Then the word "manager" became unfashionable.

Controller, Helper, Util, Governor.

Pick any, or invent your own.

There can be many managers, but only one CEO. So maybe: AudioCEO, StreamingCEO, etc... :)

But even CEOs can answer to shareholders and a board of directors, so I propose Dictator.

AudioDictator, StreamingDictator, VoipDictator...

I thought this was standard practice, but maybe it's just convergent evolution.

Better naming pattern: SingletonAntipattern*.

In libraries and many kinds of software, yes, especially on the web. However in games it can often be quite reasonable to use singletons. He gives a great example with TheVoip. You're extremely unlikely to have a game that actually needs to handle multiple voip connections at the same time, nevermind voice inputs.

Also, singletons are great in robotics control software. It removes a lot of complexity if you have one singleton corresponding to one device.

What happens if you add a second camera?

The actor/CSP model makes each device a separate process, which can be hooked together with processing nodes works wonderfully.

> What happens if you add a second camera?

You call it TheSecondCamera, duh.

TheCameraArray[1]

If there's the potential for multiples then I'll have a CameraManager (TheCameraManager) that finds out what's connected to the system and provides enumeration and access. I'll generally try to make the cameras look like a singleton and hide the Camera class. Sort of like a factory, except you'll only ever get N instances of your Camera class for N cameras.

Until you port your multiplayer game to the Xbox One where each controller has it's own mic/headset.

I would imagine John Carmack ought to know how to handle and prepare for videogame ports by now.

I'm sure he does, his games have been ported to a good number of platforms! That said he tends to be very PC-centric and in pushing that platform makes decisions that make for difficult ports (eg megetextures).

For programmers who have not been through the process of evolving game design and engine requirements getting the balance of flexibility and productivity is tricky. Hoping the fact JC uses singletons does encourage them to be sprinkled more liberally than they already are!

So then you change the code. Or make the singleton handle several things.

Yeah. Trade off is whether changing the code (which may have been referenced everywhere in the codebase) every time this happens cost more (in dev and debugging time) than not using the singleton in the first case.

It's things like this that turn a 'sure, we can make this game split-screen' into 'you didnt tell us you wanted split screen, that's gonna take a while'.

Well, this is very hypothetical. I go by "you aren't gonna need it" and "do the simplest thing that could possibly work." Maybe I'll have to change a bunch of stuff when someone suddenly comes up with a split-screen requirement. I probably will have to change a bunch of stuff anyway. As long as the code isn't impossible to understand and change, I would in most cases prefer to add split-screen support once I know for sure I need it.

That still doesn't explain how the singleton is better / easier. It just explains why it's not that bad.

Singletons in multicore environments are dangerous, one bottleneck to rule them all.

IMHO, like most patterns, the pattern is appropriate in some situations and not always an anti-pattern. It only becomes an anti-pattern when it is abused in situations where it is not appropriate.

For example, how would you go about implementing a connection pool without a singleton? Even if you pass it around everywhere, it's still a singleton, just explicit instead of implicit.

What if you have two types of connection pools?

Then you have a singleton containing singleton pools.

The problem (at least one of the biggest problems) with singletons is exactly that the singleton state is explicit. Making a singleton explicit means making it global, which allows random code all over the place to take direct dependencies on it. This increases coupling, and also makes it hell when you realize you were wrong and you need two instances of the singleton.

To your example of the connection pool, there is absolutely no reason that this has to be a singleton. You could have N connection pools, each with their own pool of connections, just as you could have N thread pools, or N memory heaps. This is not only possible but sometimes preferable, if different subcomponents need resource isolation (so that some connection-hungry component can't starve a component that needs reasonable responsiveness for the interface, for example).

Further, most of your code shouldn't even care about the connection pool. That's a level of coupling you generally do not need. Most code should care only about an actual connection, which could be passed in. Taking a direct dependency on the connection pool when not necessary increases pointless coupling and makes changes more expensive.

A class that happens to only ever be instantiated once is not automatically a singleton. It is only a singleton if it takes steps to ensure that it can never be instantiated more than once. I don't see any reason that a connection pool would have to make sure that there are no other connection pools in the application.

Singletons are how global variables are named to pretend they're ok to abuse.

(Don't get me wrong, they are necessary)

Reply on news.ycombinator.com