When you have a large codebase with dozens of packages and thousands of classes, sooner or later comes that moment, when you have to create a newer version of something: subproject, package, class, function, etc. But you can't just remove the previous version, you must support both for some period of time. And that time is not the best time of your life, trust me.
But misfortune never comes alone. Here unexpectedly comes one of the two hardest things in computer science — naming things. And in my experience, most of developers choose the dark side — suffix
2 or similar) for new thing.
I'll try to explain, why using
old for old thing is many times better.
That awkward moment when
old is better than
Let's say we have a package
Core and we need to create a new one (and support both till the end of refactoring). Imagine that
Core is the only good name for this package, we're not going to name it differently.
What the cycle of
new approach looks like.
- in case of file-system-based autoloading (i.e. for PHP projects) rename all the classes and/or namespaces inside the package
- (some time)
Core, so now we have only
To put it mildly — weird situation. You have core package with the name
CoreNew. Put yourself in your department newbie's place. "What...? Why...? But... Oh...".
Ok, we can add one more step: renaming
CoreNew back to
Core, this makes sense.
Core. This includes renaming all classes or/and namespaces inside again. Now we have only
Corepackage, and all are happy
The latter step gives us one more
headache unwanted rename operation.
And now let's look at the
CoreOld, including all classes or/and namespaces inside
- (some time)
Here we made only one rename operation. And along all that 'some time' we had sane name for actual core package —
Core. Even more: if you for some reason can not instantly remove
old package, you can leave it, it's ok, its' name shows everybody that it's legacy code. Which can not be said about
new approach when you have legacy package named
This works for any thing, not only package.
Names are important, so make your best to keep them clean. Your code is not a house, and you are not a builder. You can and must do things otherwise: move current thing to other place and build new thing right on the foundation of that old thing. Thank you.