Programming

It doesn't mean you made the wrong decision. Changing the names has a potential cost - you break something (this is especially risky for environment variables which have insanely global scope, no static type checking, etc.).

Not changing the names has a potential cost too - causing confusion in future, wasted time, or even bugs due to the increased chance of mistakes.

I'm currently leaving a company where they almost never clean up their messes. Tons of old unused code is just left in the repo. Causes huge wastes of time.

Don't underestimate the potential cost of not keeping things orderly. There was a famous case (Knight Capital) caused by not cleaning up an old unused CLI flag and it cost them $440m and destroyed the company.

Good names matter.

If you don't refactor codebases continuously and consistently(!), the'll become a total mess over time. I've worked recently with code bases that still use DOS character encodings common before 2000 or so.

If something is purely local, in a single process, it is easy to change. But the more stuff it touches, the more difficult and laborious it gets. On the extreme end, there are things like network protocols like IPv4 which are almost impossible to get rid of.

I had a senior early on in my career who took pride in producing the smallest diff possible to solve any given ticket and I thought it was so strange -- I'm already in the file, why not clean up a bit? In hindsight, they were entirely right, and I always regret doing just a little cleanup without it being strictly necessary.

Better to break things in staging than prod.

"Let me just clean this thing aaaaaand it's gone"

Yes, guilty. But also no longer regretting it a year later now that there's a clear naming scheme and structure and I can easily find what I'm looking for.

When refactoring, it always gets worse before it gets better. So, make sure to finish it so you get to the "better" state and don't leave it at "worse"

If you are doing a rename you should have it look for the new environment variable and then fall back to the old one if it's not set. Log an error when that occurs, and then slowly go through and remove the old environment variables in your deploy code, then remove the compatibility code

I feel like it depends on the project.

Typically in the ones I work on, whenever I spot an inconsistency I fix it no matter how much of a mess that causes. Yes it hurts at first, but it may hurt more down the line when the weirdnesses accumulate to the point where it impacts operations and it'll be a much bigger problem to fix.

However, I can totally see a more chill strategy work better for a project that is mostly just relatively simple code, like perhaps some website deployments. In my opinion it depends a lot on whether the code is generally already complicated, which is when you'll typically want to refactor earlier than later.

• $variable1
• $othervariable
• $july2014fixvariable
• $notneeded

...and finally...

*$otherothervariable

These shall be the variable names until the heat death of the universe! Blessed be! So say we all!

The problem with renaming environment variables is that you don't always control the environment.

I've not done this specifically, but I know the pain of wanting to make things neat and it breaking things. Then having to live with the unsatisfying setup instead of making everything symmetrical and scratching my brain itch.

This is one of those things that break two golden rules. Minimal change, or consistency? The only further variable a most senior person considers is the brittleness of the environment and deployment process.

"If it aint broke don't fix it"

At a place years ago, I misspelled a word (stupid English) which made its way into the APIs our FE consumed. FE guy decided to do a quick find/replace and broke prod. He missed some files.

(One of oldest database tables also had a spelling error from the site's first dev because English sucks)

Edit: WTAF, autocorrect?