
I have moved to naming global singletons with a The* prefix - swalsh
https://twitter.com/ID_AA_Carmack/status/575788622554628096
======
StephenFalken
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.

~~~
Shivetya
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.

------
oneeyedpigeon

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

~~~
kasabali
and off-by-one errors.

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

~~~
hoopism
There are only 10 hard problems in Computer Science.

~~~
sp332
Nobody expects the cache invalidation!

~~~
GrantSolar
One person expects the off-by-one error!

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

------
perdunov
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.

~~~
logfromblammo
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.

~~~
teacup50
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.

~~~
logfromblammo
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.

~~~
perdunov
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.

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

Then the word "manager" became unfashionable.

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

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

AudioDictator, StreamingDictator, VoipDictator...

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

------
CmonDev
Better naming pattern: SingletonAntipattern*.

~~~
Mithaldu
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.

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

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

~~~
midnightclubbed
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!

