- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
--what you imagine when you hear "PHP app" in 2019--
I image well architected, maintainable, performant and designed piece of work. But I don't think that's what you were trying to convey here :-p This code reminds me of the early PHP days. We had a saver.php file in a CMS that a colleaugue built. It worked perfectly and was SQL injection free after some tweaking. But it was over 1000 lines long and basically was a one-size-fits-all solution for any CRUD action you could imagine in the CMS. The good part was that creating a CRUD module only required you to build a config array and a matching form... Still, I don't miss it one bit.
Admin
Programmers need to remember that they were created in his image, but should not try to be him. There's only one God.
Admin
Not sure why the author "still couldn't tell you exactly what all this does". It appears to be a function for searching/finding/selecting customers by either: first name, customer id, last name, name, phone number or DID.
$custID (if the user can set it), $_POST['fname'], $_GET['fname'], $_POST['custID'], $_GET['custID'], $_POST['lname'], $_GET['lname'], $_POST['cmpName'], $_GET['cmpName'], $_POST['phone1'], $_GET['phone1'], $_POST['phone2'], $_GET['phone2'], $_POST['phone3'], $_GET['phone3'], $_POST['DID1'], $_GET['DID1'], $_POST['DID2'], $_GET['DID2'], $_POST['DID3'], $_GET['DID3'] can all be used for SQL-injections.
I hope little bobby tables is not one of their their customers...
Admin
Ooh my God!
Admin
Of course, you don't need PHP to create this sort of monstrosity. I've seen similar code in C++, complete with a homebrew REST-ish layer that would accept requests using pretty much any action and any format. That resulted in all kinds of "fun" when the time came to try to formally document the thing. Who needs consistency in an API?
Admin
I only saw God once, He was waiting in line to use the keypunch.
Thought he was a Programmer I guess.
Admin
Delete and replace - absolutely. Working on that currently.
Remove from version control history - probably a bit overkill. I could at the very least use it during interviews of prospective job applicants.
Admin
Amateurs, they could have saved themselves a lot of typing and just used
$_REQUEST!Admin
I think I just threw up in my mouth a little.
Admin
'I image well architected, maintainable, performant and designed piece of work. ' I'd never expect that for ANY random codebase (not just PHP). Code quality ~= ( organization base quality * lines of documentation ) / ( number of people who've touched it * lines of functional code * ( 1000 * number of indian outsourcers ) )
Admin
Bug report for your computation: Possible divide by zero, because org doesn't have any outsourcing to India.
Admin
Code-level documentation is often unnecessary with self-documenting code, and this formula is a nice example -- of how not to do it. It appears to give a huge weight to the number of "indian outsourcers" while in fact they get the same weight as the number of people who've touched it. And that's apart from the /0 bug that Klimax pointed out. (Likewise, any code that was not touched by people is infinitely good by your formula, but you may be a big fan of AI.)
So if you want to talk about code quality, try starting with the man in the mirror ...
Admin
Bug accepted, and I should really have 'number of concerted codebase cleanups' on top... this equation was (obviously) pulled out of my ass, needs some real cleanup itself. Yet I think there's some truth here.
Admin
The stringy
"FALSE"and"TRUE"made me chuckle.Admin
Heh ... Thaaaat's NOTHING!
I'm currently trying to work with a stringly-typed application which constructs JSON integrations, and it generates a string version of a "Boolean" type containing "true" or "false" -- into a field whose length is constrained to be 3 characters.
Admin
"Time passed. The architects behind it left, new developers were hired, management changed over, and it gradually drifted into what you imagine when you hear "PHP app" in 2019."
What Jochem said. I'd entirely believe this was legacy work someone inherited from 2007 but this looks nothing like good modern PHP.
"I expect that there are SQL injection vulnerabilities in here somewhere. I just can't read through this well enough to find them."
Come on Mike, just read any line with SQL.
"Also, if you don't POST your query parameters, it'll pull them from the GET, so, y'know, do either. It doesn't matter. Nothing matters."
This was a common bad habit back in the times of my forefathers. Now we just use the PRG pattern/sessions where possible. At least it wasn't $_REQUEST.
On the other hand, it was literally yesterday I found one of our interns setting parameters in PDO for a SQL query as ":one", ":two", ":three"...
Admin
Haha, no indeed. I was just pointing out that I found the comment weird. Don't know why the author expects PHP to be worse in 2019 then it was in the past. PHP, like a lot of languages, allows for an incredible amount of bad practices while still delivering a working application. But the dev community has been working on that steadily for years. It's why stuff like PHP-FIG exists. Also the language itself has evolved much. So, my argument was more an exaggeration to point out that it's not as bad is it was.
Admin
"Come on Mike, just read any line with SQL."
They are hard to see through all the tears. The mind-numbing headaches that it causes don't help either.
Admin
They are hard to see through all the tears. The mind-numbing headaches that it causes don't help either. .... i'll concede that point without argument
Admin
Makes me wonder, could God write a program even HE couldn't debug?