i understand some developers like to write wrapper functions to handle tedious things, I even understand how to write dynamic SQL queries, but for the love of fucking god and sanity, NEVER FUCKING DO THIS!!!!

Yes its PHP, but its not even bad PHP, its a fucking abomination from hell of PHP.

@green-portal it takes multiple arrays and constructs a sql query, each input array contains part of the query you want to actually use,

it then reconstructs this shit show into an actual query, executes it's and returns the dataset back as an array.

Would have been quickly and easier to just write the query and move on.

This like like a really bad home brewed ORM gone wrong,

The funny part is, since "table" is just a string you could force this shit to do joins and get away with it.

Why just select *? There’s no way to select specific columns. And it doesn’t support joins

@TeachMeCode it would by adding g the join in the $table string, granted the other tables didn't have conflicting columns.

But why select columns when you can return entire tables 👀

A company I worked for did exactly this in 2012. Why not simply use an ORM for this?

Most likely someone planned to be "database agnostic" at one point and intended accompanying classes with the same interface for "whatever database you wanna use".

Which is bullshit.

@Xamenyap wonder if it's the same dev 😂

This is from a project put together back in 2015.
I just keep it running on its last legs these days.

What. The. Actual. Fuck.

.........................................................................................................................................................................................................................................................................................................

I think I'm gonna be sick.

Ah. Homebrew ORM functions.

Even the special one with no validation and no escaping

Lovely.

Painful memories.

Now see, these are the kind of devs who write spaghetti code like this and when a new dev joins as their replacement, the replacement's life becomes absolute hell trying to maintain the project.

I have also seen similar constructions and at least un one case the excuse was that you could pass this through functions adding conditions ;)

Which would make the resulting code even more impenetrable and unmaintainable of cause.

It really takes all the bad things of DBZ and wraps them in even worse code :/

Well, that is how beginner-level procedural database abstraction looks like. Obviously, curlies cost extra, there is no escaping of anything, it doesn't use prepared statements and lacks a shiton of basic features you probably want even for single-table selects.

If you upgrade this to escape names and use prepared statements, all all queries going through this are suddenly injection-proofed. After that you refactor out the actual database access one more time and use that in wrappers for all the other database operations too. Yes, you can ensure secure database access that way.

Especially in PHP there are always pitfalls, footguns and other quirks to constantly be aware of when using any standard library functionality. Wrapping everything is what i ended up doing after ten years of PHP experience. While this dev doesn't seem to be able to do it properly yet, they might become able to do it with more experience. Then the bug count might plummet (it definitely did for me).

It looks a tiny bit less cursed than the CMS Of Doom I have to deal with but it's still a complete mess!
I don't understand how PHP devs still can use `array()` instead of `[ ]`...
Fucking retards lol
Typical PHP code of a beginner with no oversight and no knowlege exchange.

@PonySlaystation Ur array() notation frustration reminded me of a time when a colleague was working with PHP 7.2 and he was doing the exact same thing.

I asked him why he was doing this and his response was "What if tomorrow we downgrade the PHP version for the project to <= 5.6"

I had to hold in laughter with all my strength.

How did you create this "screenshot"?

@PonySlaystation I use array() for initialising and defining the keys up front, but then I'm a php dinosaur myself 😏

Otherwise [] is more then enough.
But ["key"] = false several times in a row is a mess too.

@jonas-w https://carbon.now.sh/

This code feels pre-2010. How legacy is this shit?

@NoMad 2015, but there was no standards back then, devs had no oversight or reviews and direct ftp to prod was the way. No testing environment or tests of any kind. Tis was the golden age..

@Sid2006 🤣🤣🤣🤣🤣

@Sid2006 this means you were not born 2006?

@jonas-w No dude. 2006 means 20 June. I know I messed up with my username lol.

little knowledge dangerous ... something.

I have also seen similar constructions and at least un one case the excuse was that you could pass this through functions adding conditions ;)

I've seen worse.

Actually I've done vaguely similar things for very old legacy projects in the past (I've been using PHP in and out for 15 years) but I atleast used prepare statements - and I don't remember implementing a satanic mixture of arrays and implode methods.

Violence is never the answer.. but in this case i'll allow it 👍

@ojt-rant I’ve written a much cleaner version of that as well. But that was before I knew about ORM.

@TeachMeCode these days if I'm using PHP with a DB it's either via Laravel (eloquent) or Typo3 (mostly eloquent, but quite terrible)

@PonySlaystation I was going to say just that, no oversight and no knowledge exchange.

I worked in very small situations where I was the only developer and sometimes I fear I took the wrong path.

I was always aware that something was not right and could be done better but pressure, lack of time, low payment and no confrontation with others bring people to that.

Luckily I am out of those situations

That's the second time that I see someone doing this on devrant...

lol, smells like nostalgia.
a rotten egg fart nostalgia.