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 »

pseudopresence: Mar 3, 2005; I want to get online...
I need a computer!

tef posted:

this for new cobol title

Hell yes.

# ? Jun 9, 2009 13:10

Adbot: ADBOT LOVES YOU

# ? May 14, 2024 00:31

zootm: Aug 8, 2006; We used to be better friends.

tef posted:

this for new cobol title

# ? Jun 9, 2009 13:48

csammis: Aug 26, 2003; Mental Institution

tef posted:

*this for new cobol title

# ? Jun 9, 2009 16:47

thesaddestpirate: Mar 19, 2005

tef posted:

this for new cobol title

# ? Jun 9, 2009 18:43

NotShadowStar: Sep 20, 2000

tef posted:

for(cobol_title){ new(this); }

# ? Jun 9, 2009 19:16

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

tef posted:

[cobol setTitle:self];

# ? Jun 9, 2009 21:12

geetee: Feb 2, 2004; >;[

I try to not look at the ORM code someone wrote for the homegrown PHP framework we use at my job. I could stop there... A co-worker just IMed me this gem:

code:

if ($keyword = isset($attribs['__select_keyword']) ? $attribs['__select_keyword'] : NULL) 
{
    $query = "SELECT $keyword * FROM " . $db_name;
}

I guess someone had just learned about the ternary operator.

# ? Jun 9, 2009 21:17

Pooball: Sep 21, 2005; Warm and squishy.

geetee posted:

I try to not look at the ORM code someone wrote for the homegrown PHP framework we use at my job. I could stop there... A co-worker just IMed me this gem:
code:
if ($keyword = isset($attribs['__select_keyword']) ? $attribs['__select_keyword'] : NULL) 
{
    $query = "SELECT $keyword * FROM " . $db_name;
}
I guess someone had just learned about the ternary operator.

I don't see how this could be done any better. It probably started out as "if ($keyword = $attribs['__select_keyword'])" and got changed to avoid an undefined variable warning.

There's no way to do this without repeating the $attribs, and the code keeps the repetition to a single line.

# ? Jun 10, 2009 07:42

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

Pooball posted:

I don't see how this could be done any better.

Factor out the isset check

code:

if ($keyword = get_if_isset($attribs['__select_keyword'])) 
{
    $query = "SELECT $keyword * FROM " . $db_name;
}

and write get_if_isset once, instead of abusing the poo poo out of the ternary operator?

# ? Jun 10, 2009 09:02

Fehler: Dec 14, 2004; .

But then you'd get a warning if $attribs['__select_keyword'] is not defined. I guess you could do get_if_isset($attribs, '__select_keyword'), but that's not that nice either.

# ? Jun 10, 2009 11:57

Bhaal: Jul 13, 2001; I ain't going down alone; Dr. Infant, MD

A certain API's string class was the cause of a rather unfun bug to chase down tonight. Like some master spy it infiltrated the very workforce of the file parser's data massaging and failsafe routines. Then it used its art of misdirection to shift blame far downfield, where the explosions were actually taking place.

Here's some of the functions at random. Pretty standard stuff:

replace(a,b) // swaps instances of a with b
toUpper() // TAKE A GUESS
insert(a,b) // insert b at position a
arg(a,...) // replace "%0", "%1" etc with each supplied arg (think printf-style)
trimmed() // remove leading and tailing whitespace
append(a) // append a to string

The ones in bold make the changes to 'this' and return a reference to itself. The ones without bold return a new object (by value) with the old one unchanged.

Now just imagine a bug due to this lurking in a file format parser, with endless lines of strings being chained through function after function, reused and reassigned and chained through something else all over.

# ? Jun 10, 2009 12:27

Pooball: Sep 21, 2005; Warm and squishy.

Fehler posted:

But then you'd get a warning if $attribs['__select_keyword'] is not defined. I guess you could do get_if_isset($attribs, '__select_keyword'), but that's not that nice either.

You can do it with references, ie.
function get_if_set(&$x) { if (isset($x)) { return $x; } else { return null; } }

# ? Jun 10, 2009 12:28

tef: May 30, 2004; -> some l-system crap ->

Bhaal posted:

The ones in bold make the changes to 'this' and return a reference to itself. The ones without bold return a new object (by value) with the old one unchanged.

This has been coming up recently in the python thread. Nice to see it catching someone out

# ? Jun 10, 2009 15:24

geetee: Feb 2, 2004; >;[

Well, $keyword is never used again, so I think this would be a little more straight forward:

code:

if ( isset($attribs['__select_keyword']) ) 
{
    $query = "SELECT {$attribs['__select_keyword']} * FROM {$db_name}";
}

code:

if ( isset($attribs['__select_keyword']) ) 
{
    $keyword = $attribs['__select_keyword'];
    $query = "SELECT {$keyword} * FROM {$db_name}";
}

code:

$keyword = isset($attribs['__select_keyword']) ? $attribs['__select_keyword'] : NULL
if ($keyword) 
{
    $query = "SELECT {$keyword} * FROM {$db_name}";
}

Maybe I'm being overzealous with this short piece of code, but I loving despise using the ternary operator inside a conditional statement. In fact, I'm really not a fan of assignment in a conditional statement most of the time either.

I'm mostly mad that there is zero enforcement of coding standards here, so every 10 lines looks completely different.

# ? Jun 10, 2009 15:53

McGlockenshire: Dec 16, 2005; GOLLOCKS!

It can be further reduced to this. Yes, it should work. I think. Erk, been too long.

code:

if(isset($attribs['__select_keyword']))
    $query = "SELECT {$attribs['__select_keyword']} * FROM {$db_name}";

# ? Jun 11, 2009 08:42

Mario Incandenza: Aug 24, 2000; Tell me, small fry, have you ever heard of the golden Triumph Forks?

code:

my $dt = DateTime->now;
$dt = $dt->subtract(days => 1);
my %months;

$months{1} = '31';
$months{2} = '28';
$months{3} = '31';
$months{4} = '30';
$months{5} = '31';
$months{6} = '30';
$months{7} = '31';
$months{8} = '81';
$months{9} = '30';
$months{10} = '31';
$months{11} = '30';
$months{12} = '31';

my $is_leap  = $dt->is_leap_year;
if ($is_leap) {
  $months{2} = '29';
}

Yes, let's create some DateTime objects which can do date math, and then roll our own. Yes, August has 81 days. Yes, let's do all this complicated poo poo just to generate a date range to pass into a database... which has its own date functions for this sort of thing.

:ughh:

# ? Jun 11, 2009 11:04

geetee: Feb 2, 2004; >;[

McGlockenshire posted:

It can be further reduced to this. Yes, it should work. I think. Erk, been too long.
code:
if(isset($attribs['__select_keyword']))
    $query = "SELECT {$attribs['__select_keyword']} * FROM {$db_name}";

The best trolls are the ones that aren't obvious. gently caress your brace stripping ways :mad:

# ? Jun 11, 2009 19:04

McGlockenshire: Dec 16, 2005; GOLLOCKS!

geetee posted:

The best trolls are the ones that aren't obvious. gently caress your brace stripping ways

It's the closest I can get to Perl's "expression if/unless expression" syntax. PHP! :bahgawd:

# ? Jun 11, 2009 20:29

Intel Penguin: Sep 14, 2007; hooray

I like this thread but I'd just like to point out that orphaned variables are not by any means a coding horror.

# ? Jun 11, 2009 21:03

tef: May 30, 2004; -> some l-system crap ->

PHP is, though.

# ? Jun 11, 2009 22:51

Lexical Unit: Sep 16, 2003

Found this in a Perl script today

code:

if (false) { ... }

Of course there was no use::strict in the file.

# ? Jun 11, 2009 23:40

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

Lexical Unit posted:

Found this in a Perl script today
code:
if (false) { ... }
Of course there was no use::strict in the file.

I should hope there wasn't

# ? Jun 11, 2009 23:42

Lexical Unit: Sep 16, 2003

Yeah because it wouldn't run if it had it :v:

Edit: I see what you mean: s/::/ /

Lexical Unit fucked around with this message at 00:59 on Jun 12, 2009

# ? Jun 11, 2009 23:44

Ensign Expendable: Nov 11, 2008; Lager beer is proof that god loves us; Pillbug

Maybe someone was too lazy to comment out the entire if structure.

# ? Jun 12, 2009 02:10

Lexical Unit: Sep 16, 2003

That was surely their intention, but w/o use strict the bare text false becomes a string literal which evaluates to true :banjo:

# ? Jun 12, 2009 03:27

trex eaterofcadrs: Jun 17, 2005; My lack of understanding is only exceeded by my lack of concern.

Lexical Unit posted:

That was surely their intention, but w/o use strict the bare text false becomes a string literal which evaluates to true

more evidence of this:

Shaggar posted:

any language that starts with p is terrible.

# ? Jun 12, 2009 04:11

karms: Jan 22, 2006; by Nyc_Tattoo; Yam Slacker

Lexical Unit posted:

That was surely their intention, but w/o use strict the bare text false becomes a string literal which evaluates to true

Seriously? :doh:

# ? Jun 12, 2009 08:21

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

Mercator posted:

Seriously?

I don't think I've ever seen more obvious proof that Larry Wall is just trolling the entire programming language community with Perl. There's no other explanation for the poo poo that goes on there.

# ? Jun 12, 2009 14:00

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

This* is why warnings and strict should have defaulted to on since like 1995

_{*among many other things}

# ? Jun 12, 2009 17:26

Mustach: Mar 2, 2003; In this long line, there's been some real strange genes. You've got 'em all, with some extras thrown in.

Nope, sorry, don't wanna break backwards-compatibility with all of the high-quality software that depends on barewords

# ? Jun 12, 2009 17:42

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

Otto Skorzeny posted:

This* is why warnings and strict should have defaulted to on since like 1995

_{*among many other things}

Ummmmm gently caress you buddy? Barewords are a great way of cutting out a few keystrokes in Perl Golf.

# ? Jun 12, 2009 17:58

implicit: Jun 26, 2005

code:

subtreeExecuteWin32Op( Win32OpRestoreWin32WindowPosRectAndClearInternalWindowPosRectAuthorityLock );

Win32OpRestoreWin32WindowPosRectAndClearInternalWindowPosRectAuthorityLock was the only member of an enum that was only ever used as the argument to subtreeExecuteWin32Op() (which itself did not actually do any useful work, but that is an entirely different story)

# ? Jun 13, 2009 18:41

tripwire: Nov 19, 2004; _{ghost flow}

implicit posted:

code:
subtreeExecuteWin32Op( Win32OpRestoreWin32WindowPosRectAndClearInternalWindowPosRectAuthorityLock );
Win32OpRestoreWin32WindowPosRectAndClearInternalWindowPosRectAuthorityLock was the only member of an enum that was only ever used as the argument to subtreeExecuteWin32Op() (which itself did not actually do any useful work, but that is an entirely different story)

Wow, very descriptive variable names! It's like you don't even need comments, it just explains itself

# ? Jun 13, 2009 20:09

Fart Amplifier: Apr 12, 2003

I recently started at the IT department at a school district. As I am the SQL "expert" (read: I have seen SQL before), I was tasked with exporting the data from the student records system we were moving away from into the templates provided for us by our new student records system vendor.

The database is Postgres, the front end is Java, and it's common for the system to crash during report card season, not to mention the general all round terrible performance.

So I look in, and see a billion instances of the following:

code:

          Table "public.sections_in_blocks"
     Column      |         Type          | Modifiers
-----------------+-----------------------+-----------
 section_name    | character varying(20) | not null
 course_name     | character varying(40) | not null
 course_id       | character varying(20) | not null
 course_credits  | character varying(20) | not null
 course_gender   | character varying(1)  | not null
 block_name      | character varying(40) | not null
 semester_number | integer               | not null
 pattern_name    | character varying(40) | not null
Indexes:
    "sections_in_blocks_pkey" PRIMARY KEY, btree (section_name, course_name, course_id, course_credits, course
_gender, block_name, pattern_name, semester_number)
    "sections_in_blocks_blocks_idx" btree (block_name, semester_number, pattern_name)
Foreign-key constraints:
    "$1" FOREIGN KEY (section_name, course_name, course_id, course_credits, course_gender) REFERENCES sections
(section_name, course_name, course_id, course_credits, course_gender) ON UPDATE CASCADE ON DELETE CASCADE
    "$2" FOREIGN KEY (block_name, semester_number, pattern_name) REFERENCES blocks(name, semester_number, patt
ern_name) ON UPDATE CASCADE ON DELETE CASCADE

Apparently someone discovered that you have to do way less joins if you include all the data in every table. And o hay, with ON ... CASCADE you can change the course name in sections_in_blocks, where it references sections, where it references courses! Relational databases are fun!

So, every year, at every school is in its own seperate database (school A 2007-08 is a different DB than school A 2008-09). I can work with that, because we are submitting the templates on a school by school basis.

Alright, so I need to export the contacts for each student (parents, emergency, etc). Alright, so there is this nice student_contacts table, which has all the contact info I need, and nicely references the students table. Well this should be easy!

code:

WRONG

Turns out, that if I want sparsly populated and incorrect (but still updated somehow to this day) contact info, then I should be pulling from the student_contacts table. If I want the actual correct information, I should pull from the central database that has a table of district wide users which includes teachers, staff, administrators, students, and student contacts. :suicide:

Apparently this district-wide database was the original database. Then, they decided to move away from that to their database-per-school-per-year structure. Not all the way though, just kind of. Queries still needed to be run district wide, and it's much easier to run a query when you're running it against 1 database instead of 140.

Also, I was told not to bother with exporting old marks/grades. "They're not stored correctly. Some of them date back to the early 1900's for some reason." I guess I have a bit of sympathy for the guys trying to maintain a 100-year-old database. I imagine the upgrade to finally using transistors was a tough migration.

EDIT: Also I hilariously forgot that the dates are split up into seperate fields (month, day, year). They are stored as strings. The month field is zero-indexed, so January is month 0, and december is month 11. The day field is not.

Fart Amplifier fucked around with this message at 21:48 on Jun 15, 2009

# ? Jun 15, 2009 17:46

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

code:

// Split up b/c compiler is issuing warnings when functions get too long

This is in the "unit test" suite :gonk:

# ? Jun 15, 2009 18:10

BigRedDot: Mar 6, 2008

Flobbster posted:

I don't think I've ever seen more obvious proof that Larry Wall is just trolling the entire programming language community with Perl. There's no other explanation for the poo poo that goes on there.

I completely agree, but this was the proof for me:

code:

bryan@Laptop-2 ~ $ perl -e 'print 3*undef; print "\n"'
0

As you can see Larry Wall is trolling all of mathematics, as well. Actually, the fact that perl used to default to dynamic scoping in the past was what clued me in.

# ? Jun 15, 2009 19:15

tef: May 30, 2004; -> some l-system crap ->

sort {$a+=$b} @list;

# ? Jun 16, 2009 01:29

Calipark: Feb 1, 2008; That's cool.

Even with my incredibly feeble understanding of programming, I find myself rolling my eyes at some of the stuff you guys are posting.

It baffles me how the people responsible made it into the work place.

This thread also provides a great source of "DON'T DO THIS" for a someone learning their first language.

# ? Jun 16, 2009 01:56

Filburt Shellbach: Nov 6, 2007; Apni tackat say tujay aaj mitta juu gaa!

Otto Skorzeny posted:

This* is why warnings and strict should have defaulted to on since like 1995

_{*among many other things}

(USER WAS PUT ON PROBATION FOR THIS POST)

# ? Jun 16, 2009 02:06

Adbot: ADBOT LOVES YOU

# ? May 14, 2024 00:31

A A 2 3 5 8 K: Nov 24, 2003; Illiteracy... what does that word even mean?

http://codytaylor.org/?p=14122

# ? Jun 16, 2009 04:08

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 »