There is one thing that will haunt me forever.
In my old job I was asked to fix some PHP code written by a guy who recently left the company.

Not only passwords were hardcoded in the code, but also he named all the variables like $a, $b, $c. And I still wonder, how comes he was not fired but left on his own terms?

As a matter of fact in many companies delivering features are of more importance than writing clean code.

Just be glad there wasn't any $$. I used to bump into it frequently. That shit exists exclusively to improve job security.

From what I've seen, developers of that kind roll in as a group, and therefore arrive with a form of herd immunity. If you have enough shitty developers, the business types assume that shitty code is actually good code.

@Lor-inc I remember writing some $$travesty. Looking back it's pretty cringe.

I've found two or three legitimate uses for its ilk in recent years, but that's it.

@Root The only one I see is loading variables from data structures into global scope before calling the template, provided nothing will happen after the template that the variables could fuck up.

@Lor-inc
1) Object chain transversal for data lookups, saved in configuration. e.g. dashboards, "trigger ___ when any of these change," etc.
2) In a risk engine: per-merchant rules to call

Both whitelisted, obv.

You could argue that the actual object path or asset names could/should be shielded, and you would be right for public / semi-public info, but for internal only it's actually better because it's less confusing and therefore easier to maintain.