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 »

Volte: Oct 4, 2004; woosh woosh

Jabor posted:

So this may or may not count as a horror:

http://openradar.appspot.com/13128709

checkDataDetectors routes any file:// uris (regardless of case) to DDResultCopyExtractedURL.
DDResultCopyExtractedURL asserts that the string it gets starts with the exact characters "file://".

At the very least, someone needs to write more comprehensive unit tests.

That's not a coding horror, it's just a bug.

# ? Feb 2, 2013 18:29

Adbot: ADBOT LOVES YOU

# ? May 21, 2024 05:16

Frozen Peach: Aug 25, 2004; garbage man from a garbage can

pigdog posted:

What could possibly go wrong with a presumption like that?

Once again, all done years before my time with the company, and a terrible hold over from their mainframe days. My personal horror was just the INT(10,0) which I found hilarious and have no idea what I was thinking.

# ? Feb 2, 2013 19:30

Freakus: Oct 21, 2000

I worked on a system that used the date 1/1/2010 to mean "forever". The funniest thing was, when 2010 rolled around, they wanted to use 2015 for their next forever date.

# ? Feb 2, 2013 19:41

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

Freakus posted:

I worked on a system that used the date 1/1/2010 to mean "forever". The funniest thing was, when 2010 rolled around, they wanted to use 2015 for their next forever date.

Now that was code that made me laugh.

Unity has its own Mathf class, that contains float versions of Math-functions.
First I thought that they might be savegely optimized float version of normally double-precision functions. Nope:

C# code:

public static float Pow (float f, float p)
{
	return (float)Math.Pow ((double)f, (double)p);
}

Convinience functions are fine too, and I'm not complaining about optimization.
I'd say that this was code that made me "heh".

# ? Feb 2, 2013 20:29

Zamujasa: Oct 27, 2010; Bread Liar

Freakus posted:

I worked on a system that used the date 1/1/2010 to mean "forever". The funniest thing was, when 2010 rolled around, they wanted to use 2015 for their next forever date.

We did that, except upper bound on a date search query was set a year away (it couldn't be too far into the future). Mar 1 2012 at the time. That day rolls around and suddenly most of our stuff doesn't work any more.

Boss's solution? Just make it say 2014 instead. :downs:

Nevermind that he could've just used the Date object in VB6 and added a year to the current time.

Luckily, the entire thing was replaced before that particular bomb.

# ? Feb 2, 2013 23:41

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

Yeah I had a similar setup with the Planned Maintenance system I built. Only I added 100 years to the current time. I figured when equipment started lasting more than a hundred years without any maintenance required Python wouldn't be a language anymore.

# ? Feb 2, 2013 23:57

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

Freakus posted:

I worked on a system that used the date 1/1/2010 to mean "forever". The funniest thing was, when 2010 rolled around, they wanted to use 2015 for their next forever date.

A whole bunch of PHP sites which used "current date, plus 25 years" to mean "forever" for cookie storage just started to break within the last couple of weeks.

Apparently it was built into a framework at some point, which explains why it was so common.

Seriously, though. 25 years? If your users don't come back to your site after 1 year, you've probably lost them. Trying to keep the cookie for that long even may not be worth trying. Also, why in the gently caress couldn't you just renew the cookie each time they visit?

Oh, and my own encounter with this "magical future date":

php:

<?
function getFarFutureTime() {
        /* This is used to set a cookie to expire some time in the future.
        We'll make it 31/12/2025 so that an update to the site should be done before then.
        This is how Y2K style bugs are started, but if this is site remains unmodified
        till 2025, i'll do the update pro bono :) */
        $thetime = mktime(10,10,10,12,31,2025);
        return $thetime;
}
?>

# ? Feb 4, 2013 02:43

Stubb Dogg: Feb 16, 2007; loskat naamalle

NVM, it apparently was april fools joke. It was believable enough though, because there have been worse things out there.

http://openjdk.java.net/jeps/154

Stubb Dogg fucked around with this message at 10:52 on Feb 4, 2013

# ? Feb 4, 2013 10:49

mutex: Jun 6, 2011

code:

import helpers as magic_stats

...

elif mode == 'duration':
    sfunc = 'proj_agg_duration'
    callable = getattr(magic_stats, sfunc)

    temp = {}
    temp = callable(start_date, end_date, 'thisyr_')
    extra_context.update(temp)

Came across this in a Django project today. It was written by a very expensive contractor

# ? Feb 4, 2013 12:02

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

mutex posted:

code:

import helpers as magic_stats

...

elif mode == 'duration':
    sfunc = 'proj_agg_duration'
    callable = getattr(magic_stats, sfunc)

    temp = {}
    temp = callable(start_date, end_date, 'thisyr_')
    extra_context.update(temp)

Came across this in a Django project today. It was written by a very expensive contractor

I don't know anything about Django so I don't really know what's up with this. Is it just that it's several more lines than it needs to be?

code:

elif mode == 'duration':
    extra_context.update(magic_stats.proj_agg_duration(start_date, end_date, 'thisyr_'))

# ? Feb 4, 2013 12:37

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

The way it pulls the proj_agg_duration function dynamically from the "magic_stats" module is needlessly complex if the pasted code is all there's to it, but when I look at it it makes me think there probably is or has been some alternative way for the "magic_stats" module to be loaded from somewhere else depending on some branching logic further up. If the developer straight up doesn't know that you can do magic_stats.proj_agg_duration(...) then yeah, that's a horror.

# ? Feb 4, 2013 13:42

mutex: Jun 6, 2011

Yeah, that's pretty much all there is to it

The same code is copy/pasted in to something like 10 other elif cases with sfunc set to something else in each one. Also 'callable' is a built in function and this code is overwriting it: http://docs.python.org/2/library/functions.html#callable

# ? Feb 4, 2013 14:30

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

mutex posted:

Yeah, that's pretty much all there is to it

The same code is copy/pasted in to something like 10 other elif cases with sfunc set to something else in each one.

Oh, that's even worse in that case. The author doesn't know how the "use a dictionary as a switch statement" idiom works.

# ? Feb 4, 2013 14:51

cliffy: Apr 12, 2002

mutex posted:

Came across this in a Django project today. It was written by a very expensive contractor

Perhaps they farmed it out to several inexpensive developers across the pacific? Or they're just bad.

# ? Feb 4, 2013 14:55

Polio Vax Scene: Apr 5, 2009

Everybody posted:

Magical Future Dates

Apparently I'm part of this club too this morning. Someone here must have thought the world really would end on December 21st because there was no preparation for the 2013 fiscal year.

# ? Feb 4, 2013 17:21

Catalyst-proof: May 11, 2011; better waste some time with you

I have never in my life needed to choose some magical date in the future that is never reached. Why would you ever need this? YOu can't be comparing it to other dates, right? Because otherwise you could just make some object that returned the right comparators for a date that's always later than any other date?

# ? Feb 4, 2013 17:37

Doctor w-rw-rw-: Jun 24, 2008

WHOIS John Galt posted:

I have never in my life needed to choose some magical date in the future that is never reached. Why would you ever need this? YOu can't be comparing it to other dates, right? Because otherwise you could just make some object that returned the right comparators for a date that's always later than any other date?

My workplace's magical future date is 9999-01-01-00:00:00 or something along those lines. I believe it was to store the logical date of 'never' for stuff like release dates / availability in a MySQL database field for each given piece of media. 'Always' is 0000-01-01-00:00:00. Inline 'always' and 'never' make sense but IMO not much else. A non-maximum or non-minimum value just seems kind of ludicrous for a logical value with that kind of meaning.

# ? Feb 4, 2013 17:52

Polio Vax Scene: Apr 5, 2009

WHOIS John Galt posted:

I have never in my life needed to choose some magical date in the future that is never reached. Why would you ever need this? YOu can't be comparing it to other dates, right? Because otherwise you could just make some object that returned the right comparators for a date that's always later than any other date?

I'm not a SQL expert but I think it might be that it's faster to provide some fixed date that will 'never' qualify (or 'always' qualify) than to compute/allocate one on the fly.

Either that or the more likely answer: our predecessors were idiots.

# ? Feb 4, 2013 17:59

Pardot: Jul 25, 2001

Manslaughter posted:

I'm not a SQL expert but I think it might be that it's faster to provide some fixed date that will 'never' qualify (or 'always' qualify) than to compute/allocate one on the fly.

Either that or the more likely answer: our predecessors were idiots.

Yeah, I just use Infinity for forever in the future cause that's what it means.

SQL code:

=# insert into times values (now());
INSERT 0 1
Time: 0.649 ms
=# insert into times values ('infinity'::date);
INSERT 0 1
Time: 0.359 ms
=# select * from times;
             time              
-------------------------------
 2013-02-04 08:57:18.827499-08
 infinity
(2 rows)

# ? Feb 4, 2013 18:03

Catalyst-proof: May 11, 2011; better waste some time with you

Manslaughter posted:

It's faster to provide some fixed date that will 'never' qualify (or 'always' qualify) than to compute one on the fly.

I didn't say anything about computing one on the fly. I guess if you're storing something in a database and need an actual date, it makes sense to choose some value, but I meant something more like

Python code:

from datetime import datetime

class AlwaysLater(datetime):
  def __lt__(self, other):
    return False

now = datetime.now()
now > datetime(year=1992,month=1,day=3) # True
now > AlwaysLater(year=1992,month=1,day=3) # False

# ? Feb 4, 2013 18:08

TheresaJayne: Jul 1, 2011

Bunny Cuddlin posted:

Seriously? I didn't even realize this person was a woman until I read this post. What does this have to do with gender?

Nothing, and there are plenty of female programmers... Me included.

# ? Feb 4, 2013 18:33

Bunny Cuddlin: Dec 12, 2004

WHOIS John Galt posted:

I have never in my life needed to choose some magical date in the future that is never reached. Why would you ever need this? YOu can't be comparing it to other dates, right? Because otherwise you could just make some object that returned the right comparators for a date that's always later than any other date?

Session and cookie expiration in web frameworks is where you see this a lot. For the session thing, your framework should provide a way to set it to never expire. For cookies, however, there's no way to set it never to expire other than by choosing a date way out in the future.

# ? Feb 4, 2013 18:42

Catalyst-proof: May 11, 2011; better waste some time with you

Bunny Cuddlin posted:

Session and cookie expiration in web frameworks is where you see this a lot. For the session thing, your framework should provide a way to set it to never expire. For cookies, however, there's no way to set it never to expire other than by choosing a date way out in the future.

This is because cookies are meant to expire.

# ? Feb 4, 2013 18:48

ymgve: Jan 2, 2004; Offensive Clock

Doctor w-rw-rw- posted:

My workplace's magical future date is 9999-01-01-00:00:00 or something along those lines. I believe it was to store the logical date of 'never' for stuff like release dates / availability in a MySQL database field for each given piece of media. 'Always' is 0000-01-01-00:00:00. Inline 'always' and 'never' make sense but IMO not much else. A non-maximum or non-minimum value just seems kind of ludicrous for a logical value with that kind of meaning.

Personally, I'd use 4999-01-01 instead. So even if someone for some reason tries to add dates together, it still won't overflow.

# ? Feb 4, 2013 18:52

Zhentar: Sep 28, 2003; Brilliant Master Genius

Manslaughter posted:

I'm not a SQL expert but I think it might be that it's faster to provide some fixed date that will 'never' qualify (or 'always' qualify)

I don't know about faster, but it's definitely easier to use a dummy date and write

SQL code:

WHERE @date BETWEEN table.START_DATE AND table.END_DATE

than it is to write

SQL code:

WHERE @date BETWEEN table.START_DATE AND table.END_DATE
	OR @date >= table.START_DATE ANd table.END_DATE IS NULL

# ? Feb 4, 2013 18:54

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

WHOIS John Galt posted:

This is because cookies are meant to expire.

Even outside of cookies there are a bunch of contexts where something analogous is useful. It's not really much cleaner to have a flag that indicates whether something expires plus the expiry field than to just have the expiry field with a sentinel value that indicates the thing in question never expires.

# ? Feb 4, 2013 18:55

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

The horror here is ever using a "magic number" value to represent something with no value. If it has no value, it should be null.

# ? Feb 4, 2013 19:07

ohgodwhat: Aug 6, 2005

ymgve posted:

Personally, I'd use 4999-01-01 instead. So even if someone for some reason tries to add dates together, it still won't overflow.

But what if they try to add three or more of them together??? :v:

# ? Feb 4, 2013 20:08

Factor Mystic: Mar 20, 2006; Baby's First Post-Apocalyptic Fiction

Zhentar posted:

I don't know about faster, but it's definitely easier to use a dummy date and write
SQL code:
WHERE @date BETWEEN table.START_DATE AND table.END_DATE
than it is to write
SQL code:
WHERE @date BETWEEN table.START_DATE AND table.END_DATE
	OR @date >= table.START_DATE ANd table.END_DATE IS NULL

SQL code:

WHERE @date BETWEEN isnull(table.START_DATE, '0001-01-01') AND isnull(table.END_DATE, '9999-12-31')

# ? Feb 4, 2013 20:16

hobbesmaster: Jan 28, 2008

Ithaqua posted:

The horror here is ever using a "magic number" value to represent something with no value. If it has no value, it should be null.

Amusingly NULL being the magic number 0 occasionally causes issues in C/C derivatives.

# ? Feb 4, 2013 20:21

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

All you're doing is setting yourselves up for a Y10K problem.

# ? Feb 4, 2013 20:23

Polio Vax Scene: Apr 5, 2009

Don't worry I'll remember to fix it when I'm cryogenically revived six thousand years from now

# ? Feb 4, 2013 20:26

Freakus: Oct 21, 2000

Ithaqua posted:

The horror here is ever using a "magic number" value to represent something with no value. If it has no value, it should be null.

I'm not sure where you got the idea that forever equates to no value. E.g. if I were storing a date for how long an account should be free, I would expect null to mean not free rather than forever.

It's really a deficiency in programming languages. Most languages already have a concept of +/- infinity for numbers. Time should have a similar concept.

# ? Feb 4, 2013 20:52

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

Freakus posted:

I'm not sure where you got the idea that forever equates to no value. E.g. if I were storing a date for how long an account should be free, I would expect null to mean not free rather than forever.

It's really a deficiency in programming languages. Most languages already have a concept of +/- infinity for numbers. Time should have a similar concept.

To me, a date of null means "it doesn't apply," and you can write your code to interpret that in whatever way makes sense for that particular application.

# ? Feb 4, 2013 21:20

Opinion Haver: Apr 9, 2007

Ithaqua posted:

To me, a date of null means "it doesn't apply," and you can write your code to interpret that in whatever way makes sense for that particular application.

What if there are two ways that make sense? Like, if you want a date that's always in the future and a date that's always in the past?

# ? Feb 4, 2013 21:22

Polio Vax Scene: Apr 5, 2009

Ithaqua posted:

To me, a date of null means "it doesn't apply," and you can write your code to interpret that in whatever way makes sense for that particular application.

Whoever is fixing your code has to figure out what the hell your special-case program is going to do when there is a null now.

# ? Feb 4, 2013 21:27

ultramiraculous: Nov 12, 2003; "No..."; Grimey Drawer

Golbez posted:

All you're doing is setting yourselves up for a Y10K problem.

@** If this becomes an issue in 9999, pull me out of the fabric of time and I'll fix it pro bono **@

Freakus posted:

It's really a deficiency in programming languages. Most languages already have a concept of +/- infinity for numbers. Time should have a similar concept.

Objective-C has a concept of distantPast and distantFuture. It's basically positive/negative infinity. You use distantFuture for, say, a task that never expires and keeps running. I honestly thought it was more common, but I'm not seeing it elsewhere.

# ? Feb 4, 2013 22:00

mobby_6kl: Aug 9, 2009; by Fluffdaddy

Using NULLs this way is perfect material for this thread. The most consistent way to interpret NULLs that make sense to me is to think of them as unknown values, which helps explain 123 > NULL, NULL==NULL, how they behave in grouping, etc.

Speaking of dates, guess what the END_DATE field for contracts without a set end date look like in our data warehouse?

1900-01-01 00:00:00
:negative:

# ? Feb 4, 2013 22:15

Flobbster: Feb 17, 2005; "Cadet Kirk, after the way you cheated on the Kobayashi Maru test I oughta punch you in tha face!"

Ithaqua posted:

To me, a date of null means "it doesn't apply," and you can write your code to interpret that in whatever way makes sense for that particular application.

I'm working on a Rails app right now where having well-defined infinity values instead of null would be great. Assignments in the database have three dates associated with them: opens_at, due_at, and closes_at. It would be great if opens_at could default to "the beginning of time" and due_at/closes_at could default to "the end of time" for assignments that should remain accessible for ever.

Right now my code has a bunch of "if date && date < other_date" because of the possibility of null. Null sucks, and special cases suck.

# ? Feb 5, 2013 01:16

Adbot: ADBOT LOVES YOU

# ? May 21, 2024 05:16

Progressive JPEG: Feb 19, 2003

boost::date_time posted:

ptime(special_values sv)

Constructor for infinities, not-a-date-time, max_date_time, and min_date_time

ptime d1(neg_infin);
ptime d2(pos_infin);
ptime d3(not_a_date_time);
ptime d4(max_date_time);
ptime d5(min_date_time);

(with similar accessors)

# ? Feb 5, 2013 04:17

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 »