Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »

Freakus: Oct 21, 2000

bobthecheese posted:

I... I give up. Seriously, gently caress. I'm out.

Is "ConnectToDatabase" really used to execute a query?

# ? Oct 3, 2012 03:31

Adbot: ADBOT LOVES YOU

# ? May 27, 2024 09:15

McGlockenshire: Dec 16, 2005; GOLLOCKS!

Freakus posted:

Is "ConnectToDatabase" really used to execute a query?

Connect-query-disconnect is not uncommon among clueless newbies.

# ? Oct 3, 2012 05:46

nuvan: Mar 29, 2008; And the gentle call of the feral 3am "Everything is going so well you can't help but panic."

If connect->query->disconnect is not good, then what's the proper way to do it? Connect->run all queries needed->disconnect?

# ? Oct 3, 2012 06:13

bobthecheese: Jun 7, 2006; Although I've never met Martha Stewart, I'll probably never birth her child.

McGlockenshire posted:

Connect-query-disconnect is not uncommon among clueless newbies.

It's actually not that bad, thankfully (it may have been at some point in the past). It's a wrapper around mysql_query with some basic error handling, analytics, etc.

In general, with PHP, the process is:

Connect -> run all your queries -> forget about it because PHP will disconnect automatically

# ? Oct 3, 2012 06:27

Malloc Voidstar: May 7, 2007; Fuck the cowboys. Unf. Fuck em hard.

Quote-Unquote posted:

PHP has a lot of silly poo poo but strtotime is the most awesome solution I've seen for dealing with dates.

What? From looking at it I'm pretty sure it's an awful solution.

# ? Oct 3, 2012 06:29

McGlockenshire: Dec 16, 2005; GOLLOCKS!

The formats understood by strtotime are very well-defined. As long as you're not throwing pathologically poorly formed input at it, it works pretty darn well.

Letting users type "+8 weekdays" in a date field and have it just work is pretty nifty.

# ? Oct 3, 2012 06:41

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

Honestly, having a built-in library routine to turn a user-defined string into a date is a good thing, because it gives you consistency across applications instead of everyone developing their own, subtly different version.

Whether the PHP implementation is good or not, I have no clue. But the idea is good.

# ? Oct 3, 2012 07:30

Contra Duck: Nov 4, 2004; #1 DAD

McGlockenshire posted:

The formats understood by strtotime are very well-defined. As long as you're not throwing pathologically poorly formed input at it, it works pretty darn well.

Letting users type "+8 weekdays" in a date field and have it just work is pretty nifty.

Here's the problem: http://en.wikipedia.org/wiki/Date_format_by_country

# ? Oct 3, 2012 08:06

Centripetal Horse: Nov 22, 2009; Fuck money, get GBS

This could have bought you a half a tank of gas, lmfao -
Love, gromdul

-S- posted:

A new(er) developer that read the analyst's (me) requirements and carried them out in code to a T? I've seen junior devs do things like that quite a bit. Maybe we just recruit terrible junior devs.

So, you would write requirements that say, "Fetch all rows, then, if there are more than 500, go back and fetch the first 500, again," instead of, "Only fetch the first 500 rows?" Or, am I missing some obvious case where the requirements might look as if they called for such behavior?

# ? Oct 3, 2012 08:48

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

I could see requirements written as "display rows from this table; if there are more than 500 rows, only display the first 500".

# ? Oct 3, 2012 09:07

Quote-Unquote: Oct 22, 2002

Aleksei Vasiliev posted:

What? From looking at it I'm pretty sure it's an awful solution.

What makes you say that? The only real problems I've ever found (as mentioned above) are when you've got varying date formats, like using '/' instead of '-' makes PHP think you're dealing with a different international date format, etc. So long as you're aware of that it can be incredibly useful, especially for incrementing dates and times without having to worry about DST and leap years etc.

It can parse silly poo poo like "third wednesday march 2013 noon" correctly.

# ? Oct 3, 2012 10:00

nielsm: Jun 1, 2009

09.10.11

Is that 9th of October 2011, 10th of September 2011, 11th of October 2009, or 10 minutes and 11 seconds past 9 am (or pm)?

# ? Oct 3, 2012 10:47

Quote-Unquote: Oct 22, 2002

nielsm posted:

09.10.11

Is that 9th of October 2011, 10th of September 2011, 11th of October 2009, or 10 minutes and 11 seconds past 9 am (or pm)?

Point taken. What's a better way of dealing with dates from multiple date format zones then?

# ? Oct 3, 2012 11:11

Sagacity: May 2, 2003; Hopefully my epitaph will be funnier than my custom title.

ISO 8601?

# ? Oct 3, 2012 11:13

omeg: Sep 3, 2012

Quote-Unquote posted:

Point taken. What's a better way of dealing with dates from multiple date format zones then?

Time strings (and numbers and other things) are meaningless without locale/culture context. Always make sure to parse according to format your UI user is expecting.

This is probably the biggest source of fuckups in software localization.

# ? Oct 3, 2012 11:21

Quote-Unquote: Oct 22, 2002

omeg posted:

Time strings (and numbers and other things) are meaningless without locale/culture context. Always make sure to parse according to format your UI user is expecting.

This is probably the biggest source of fuckups in software localization.

Any time I have any user input on a date or time it won't just be a string, rather separate boxes for day, month, year etc. Then anything I need to do in PHP will put these back together in ISO 8601 format. strtotime becomes incredibly useful when I need to do anything with that user input, like add or subtract a particular unit of time. But I'm assuming now that DST will be a problem because strtotime will take into account DST changes in the local timezone and not necessarily the user's timezone. Whoops.

I guess I need to establish what the user's timezone and take that into account.

# ? Oct 3, 2012 11:32

big trivia FAIL: May 9, 2003; "Jorge wants to be hardcore,
but his mom won't let him"

Jabor posted:

I could see requirements written as "display rows from this table; if there are more than 500 rows, only display the first 500".

Pretty much this. Requirements have to be able to be understood by, in some cases, completely clueless clients, and so sometimes they are worded in a suboptimal way.

# ? Oct 3, 2012 13:16

Golbez: Oct 9, 2002; 1 2 3!
If you want to take a shot at me get in line, line
1 2 3!
Baby, I've had all my shots and I'm fine

nielsm posted:

09.10.11

Is that 9th of October 2011, 10th of September 2011, 11th of October 2009, or 10 minutes and 11 seconds past 9 am (or pm)?

This is not a complaint against strtotime, there's no automated system that can properly parse this. At some point you'll have to enforce a date format.

# ? Oct 3, 2012 14:20

Zombywuf: Mar 29, 2008

omeg posted:

Time strings (and numbers and other things) are meaningless without locale/culture context. Always make sure to parse according to format your UI user is expecting.

This is probably the biggest source of fuckups in software localization.

This, a million times this.

I've worked on a fairly large code base where date "parsing" was done by splitting up strings and then using switch statements to detect the 3 letter month name. With every language that didn't use the "standard" abbreviations being handled as a special case. That is, if there was a clash between an abbreviation in two languages the body of the case picked it up with an if statement.

This was in C#, a language with superb localisation facilities.

# ? Oct 3, 2012 17:25

Zamujasa: Oct 27, 2010; Bread Liar

Our move to Zend has improved our code significantly.

php:

<?
    if(isset($_POST['username']) && $_POST['password']) {
        $username    = $_POST['username'];
        $password    = $_POST['password'];

        //run the query
        $userQuery = $this->_db->query("SELECT * FROM users WHERE user = '".$username."' AND password = '".$password."'");?>

Just kidding, of course. :sigh:

The person in charge of the rewrite still has no idea what he's doing. I don't know Zend at all either (it is on my list of things to learn), but even I know that Zend has prepared queries and table objects built-in.

# ? Oct 3, 2012 17:50

Strong Sauce: Jul 2, 2003; You know I am not really your father.

The worst thing there isn't any of the code, it's the fact that there doesn't seem to be any kind of encrypting of the password that is truly the coding horror.

# ? Oct 3, 2012 18:04

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

Strong Sauce posted:

The worst thing there isn't any of the code, it's the fact that there doesn't seem to be any kind of encrypting of the password that is truly the coding horror.

I think the code is pretty bad for presenting a gaping injection vulnerability.

# ? Oct 3, 2012 18:07

Zombywuf: Mar 29, 2008

Hammerite posted:

I think the code is pretty bad for presenting a gaping injection vulnerability.

' OR 1=1; --

Everyone's favourite password.

# ? Oct 3, 2012 18:10

Zamujasa: Oct 27, 2010; Bread Liar

Yes. No encryption (strike 1), no escaping (strike 2), and not even using Zend's basic database class for a prepared query (strike 3).

We had three different areas to our (pre-Zend) site, and they all take different logins. One's stored in plaintext, one's just a basic MD5 hash, and one accepts either plaintext or a sha256-with-salt hash (that is, of course, repeated in every file instead of being defined in a function).

This was supposed to be the part where we made the code into something not a horror, but it looks like he's just pasting code from the old poo poo into a controller in Zend and calling it done. :eng99:

Zombywuf posted:

' OR 1=1; --

Everyone's favourite password.

You can squeeze that down to just ' OR 1; -- if you want to shave off two bytes or so. :downs:

# ? Oct 3, 2012 18:41

o.m. 94: Nov 23, 2009

Hammerite posted:

I think the code is pretty bad for presenting a gaping injection vulnerability.

Surely the best part of it all has to be the comment.

# ? Oct 3, 2012 18:46

NovemberMike: Dec 28, 2008

Huh. I just got a look at our Java code, all of the variables have names like hm (for a hashmap) or rs (for a result set). This is going to be fun.

# ? Oct 3, 2012 21:29

Optimus Prime Ribs: Jul 25, 2007

Zamujasa posted:

PHP code:

if(isset($_POST['username']) && $_POST['password']) {

It's like the guy thinks once you call isset it applies to everything else in the if statement.

# ? Oct 4, 2012 00:24

MrMoo: Sep 14, 2000

McGlockenshire posted:

Connect-query-disconnect is not uncommon among clueless newbies.

There was a good one on stackoverflow today: create stored procedure-execute-delete and repeat.

This one has to be a winner of something,

Patrick posted:

I have one huge C file. Within the file, there is a giant struct (~>1million lines).

http://stackoverflow.com/questions/12714925/parallel-compile-a-huge-c-file-preferrably-with-gcc

MrMoo fucked around with this message at 02:44 on Oct 4, 2012

# ? Oct 4, 2012 02:35

Zamujasa: Oct 27, 2010; Bread Liar

Optimus Prime Ribs posted:

It's like the guy thinks once you call isset it applies to everything else in the if statement.

Haha, I didn't even notice that. I've started using a helper function to get around that crap:

php:

<?
function ret(&$val) {
    return (isset($val)) ? $val : null;
}
?>

It's ugly, but it solves a problem for me. Mostly letting me do things like "$var = ret($_POST['poo poo']);" without having to wrap everything in an "(isset($var) ? $var : null)" blob.

(isset() still has its uses, however.)

# ? Oct 4, 2012 03:59

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

PHP code:

foreach($offices as $key => $value) {

	foreach($employees as $key2 => $value2) {

		if($value->hasEmployee($value2)) {
			// do some stuff
		}
	}


	foreach($jobs as $key2 => $value2) {

		if($value->hasJob($value2)) {
			// do some more stuff
		}
	}
}

$key and $key2 are never used, $value and $value2 are reused multiple times.

# ? Oct 4, 2012 07:37

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Let's try something different. Anybody know this one?

JavaScript trivia: in ES5.1 (so no cheating with let), what's the one place that has proper lexical block scoping?

# ? Oct 4, 2012 07:55

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

Wheany posted:

$key and $key2 are never used, $value and $value2 are reused multiple times.

$value2 is reused once. I don't see how $value is reused?

# ? Oct 4, 2012 07:56

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

Suspicious Dish posted:

$value2 is reused once. I don't see how $value is reused?

Well, that was just a snippet typed from memory for illustration. The actual code has multiple foreach ($someArray as $key => $value) blocks.

"$key => $value" and "$key2 => $value2" are in our code verbatim.

What bothers me is that the code is so obviously copy-pasted from php examples.

# ? Oct 4, 2012 08:07

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

Yeah it looks to me a lot like "this is the only way I know of to loop through stuff".

# ? Oct 4, 2012 08:13

Deus Rex: Mar 5, 2005

Wheany posted:

PHP code:

foreach($offices as $key => $value) {

	foreach($employees as $key2 => $value2) {

		if($value->hasEmployee($value2)) {
			// do some stuff
		}
	}


	foreach($jobs as $key2 => $value2) {

		if($value->hasJob($value2)) {
			// do some more stuff
		}
	}
}

$key and $key2 are never used, $value and $value2 are reused multiple times.

ignoring the other issues, I don't think it's a big deal to iterate over an associative array like that even if the keys will never be used in the loop body. better to make it obvious to later maintainers that the array is associative than to go for the most brevity, IMO

# ? Oct 4, 2012 08:17

Wheany: Mar 17, 2006; Spinya^{ha^{ha^haha}ha}ha_{ha_{ha_haha}ha}ha!; Doctor Rope

Deus Rex posted:

ignoring the other issues, I don't think it's a big deal to iterate over an associative array like that even if the keys will never be used in the loop body. better to make it obvious to later maintainers that the array is associative than to go for the most brevity, IMO

I'm not even sure if the arrays are used in an associative manner in this case.

# ? Oct 4, 2012 08:32

Scaevolus: Apr 16, 2007

Suspicious Dish posted:

Let's try something different. Anybody know this one?

JavaScript trivia: in ES5.1 (so no cheating with let), what's the one place that has proper lexical block scoping?

functions?

# ? Oct 4, 2012 09:32

LOOK I AM A TURTLE: May 22, 2003; "I'm actually a tortoise."; Grimey Drawer

Deus Rex posted:

ignoring the other issues, I don't think it's a big deal to iterate over an associative array like that even if the keys will never be used in the loop body. better to make it obvious to later maintainers that the array is associative than to go for the most brevity, IMO

Aren't PHP "arrays" always associative?

# ? Oct 4, 2012 10:17

Deus Rex: Mar 5, 2005

LOOK I AM A TURTLE posted:

Aren't PHP "arrays" always associative?

yes, that's true � I guess what I meant by associative was 'arrays with keys which are non-consecutive, and possibly non-integer starting from something other than 0'

# ? Oct 4, 2012 10:28

Adbot: ADBOT LOVES YOU

# ? May 27, 2024 09:15

Hammerite: Mar 9, 2007; And you don't remember what I said here, either, but it was pompous and stupid.; Jade Ear Joe

LOOK I AM A TURTLE posted:

Aren't PHP "arrays" always associative?

Yeah PHP arrays kind of roll both lists and dictionaries into one unsatisfying data structure. Technically all PHP arrays are associative no matter what but like Deus Rex says, sometimes arrays occur with 0, 1, ..., n as the keys and sometimes they are "true" associative arrays.

# ? Oct 4, 2012 10:52

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »