If this is how you write your SQL, I don't want to work there

FragFrog1

@dkf said:

The worst part is definitely the single quotes around what I guess are meant to be field references, turning them into simple string values.

I first assumed these were meant to be backticks; quite valid in MySQL, necessary even if you have retarded field names. Of course, that would mean they actually have fields called "PHPdev.sex", instead of a table "PHPdev" with a field "sex". Not sure if even backticks allow that level of crazy. Also not sure what to make of that ORDER (BY), that's just retarded no matter how you write it.

My personal favorites:

[list]
[] SELECT . Nothing says we have memory to spare quite like including every single fcking field in your resultset.
[] String match using LIKE '%'. Who cares about performance, right? Match against is for pussies after all.
[] Heredoc syntax for the query. Ok, not a WTF, but regular (double) quotes don't demand an extra line with "EOD;", and you shouldn't need it with proper parameter injection.
[] $this as external object reference. In fact, I'm fairly certain this is a syntax error, or at least wildly confusing as $this is also the protected variable for self referencing within an object.
[] Using a Company object with a public 'interview' method [i]which takes an SQL query as argument[/i]. WTF? That query should never even be exposed, let alone used as parameter.
[] Completely ignoring the result of the interview, and creating a teamMember object [i]using that same query as parameter[/i]. WTF?!
[*] String comparison using "!=". Because who needs strcmp anyway, right?
[/list]

Ben L.

@FragFrog said:

String comparison using "!=". Because who needs strcmp anyway, right?

The other ones make sense, but why this one?

FragFrog1

@Ben L. said:

@FragFrog said:
String comparison using "!=". Because who needs strcmp anyway, right?

The other ones make sense, but why this one?

String comparison in PHP can be done with the regular compare operators, but those tend to be somewhat unpredictable. Consider for example if $teamMember -> currentCity() returns true. In that case, we get: if (true != 'Munich').

Since in PHP, any string when compared to a boolean is converted to a boolean, and very few strings eval as false, this is parsed as: "if (true != true)", and thus the condition is never entered and any person living in 'true' will never have to move to Munich. And because this is all done silently, if someone ever refactors currentCity() to return true (for example, as default when the current city is not known), you won't find out untill your first non-Munich employee starts complaining about the bloody long commute from Berlin.

For these and a few similar reasons, as a rule of thumb, you should use strcmp or its illogically named brother strcasecmp if you want to compare two strings that can contain user input.

@dkf said:

@Sutherlands said:
What's so horrendous about the SQL?
The worst part is definitely the single quotes around what I guess are meant to be field references, turning them into simple string values. The query is going to do the wrong thing and the creators of it appear to have no concept of why.

It's supposed to be funny. It isn't, but someone thought they were being clever. But all that is irrelevant. If someone tells a joke, no matter how lame, and your only respone is to nitpick things like "single quotes around field references, turning them into string values" then you are TRWTF.

boomzilla

@El_Heffe said:

@dkf said:
@Sutherlands said:
What's so horrendous about the SQL?
The worst part is definitely the single quotes around what I guess are meant to be field references, turning them into simple string values. The query is going to do the wrong thing and the creators of it appear to have no concept of why.
It's supposed to be funny. It isn't, but someone thought they were being clever. But all that is irrelevant. If someone tells a joke, no matter how lame, and your only respone is to nitpick things like "single quotes around field references, turning them into string values" then you are TRWTF.

If you come to a site dedicated to talking about WTFs, no matter how picayune, and thing that is TRWTF, then you are TRWTF.

Weng

@Weng said:

@dkf said:
@Sutherlands said:
What's so horrendous about the SQL?
The worst part is definitely the single quotes around what I guess are meant to be field references, turning them into simple string values. The query is going to do the wrong thing and the creators of it appear to have no concept of why. (Also, it seems odd that there's no constraint on PHPdev knowing PHP, but that's perhaps done at the view level. Bah! Who am I kidding? Views? What's that? </cynic>)
Subtle! I'm interviewing a SQL developer candidate this afternoon, and will be printing this out for the puzzles-n-stuff part of the interview.
Better than my usual "tack our production database schema to the wall and print a stored procedure listing, and if the candidate doesn't attempt to flee, they aren't qualified" technique, anyway.

Update: Effing recruiting firm took our Senior SQL Developer ad and sent us the greenest SQL Admin I've ever met. He didn't see anything wrong. Neither with this ad nor with our (terrifying) schema nor with the most byzantine procedures I could find in our codebase. His first response when asked his steps for troubleshooting a poorly performing query was "Check the cluster config". Not included was the word "index" or any of its variants.

balazs

@dkf said:

@DCRoss said:
Just wait until you see the other functions: newAddDevices, newRealAddDevices, realAddDevices, devicesRealAddNew and realNewAddDevicesAndWeMeanItThisTime.
Nawww, it'd be addDevicesEx and addDevices2Ex. And, given that it's PHP, devices_addEx_2, and exAdd_device_s.

Then it should be iMac_add_os("iOS"); iOS_add_software...

@DCRoss said:

That's why their query sorts the applicants by salary, in ascending order.

To be fair, they sort by personality first, so they only would pick the candidate with the lowest salary from the ones with the most personality (if there even are more than one with the same amount of maximum personality, not just one, then it's just him/her/it)

On another note: No comments yet on the fact that the JOIN statements do not specify any join criteria? So does that mean they are looking for a candidate with indeterminate gender, work experience that can be expressed in a string lexicographically greater than "2 years" and looking for a permanent position, as long as there are any other candidates with the requires knowledge skills? Guess they assume it doesn't matter what you know as long as you know who to ask.

dhromed

@Weng said:

Effing recruiting firm took our Senior SQL Developer ad and sent us the greenest SQL Admin I've ever met.

That's ORDER BY salary ASC in action!

Cassidy

@Weng said:

Update: Effing recruiting firm took our Senior SQL Developer ad and sent us the greenest SQL Admin I've ever met.

This has occured far too many times for it to be surprising.

Love to hear the response to the unsuitable candidate and ~~incompetant fucktards~~ recruiting firm...

Cassidy

@Anonymouse said:

On another note: No comments yet on the fact that the JOIN statements do not specify any join criteria?

I wonder if the purpose of the code is to draw out developers by getting them to identify flaws and present alternatives?

I'm not sure I'd like to hire someone who proclaimed "I can write code like that!"

Kittemon

I can't shake the unsettling feeling that "[code]salary ASC[/code]" is the result of wishing to convey "increase your salary by taking a job with us!" and losing something in the translation.