5
msdsk
52d

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?

Comments
  • 2
    As a matter of fact in many companies delivering features are of more importance than writing clean code.
  • 1
    Just be glad there wasn't any $$. I used to bump into it frequently. That shit exists exclusively to improve job security.
  • 5
    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.
  • 0
    @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.
  • 0
    @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.
  • 0
    @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.
Add Comment