|
tef posted:this for new cobol title Hell yes.
|
# ? Jun 9, 2009 13:10 |
|
|
# ? May 15, 2024 02:25 |
|
tef posted:this for new cobol title
|
# ? Jun 9, 2009 13:48 |
|
tef posted:*this for new cobol title
|
# ? Jun 9, 2009 16:47 |
|
tef posted:this for new cobol title
|
# ? Jun 9, 2009 18:43 |
|
tef posted:for(cobol_title){ new(this); }
|
# ? Jun 9, 2009 19:16 |
|
tef posted:[cobol setTitle:self];
|
# ? Jun 9, 2009 21:12 |
|
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:
|
# ? Jun 9, 2009 21:17 |
|
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: 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 |
|
Pooball posted:I don't see how this could be done any better. Factor out the isset check code:
|
# ? Jun 10, 2009 09:02 |
|
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 |
|
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 |
|
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 |
|
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 |
|
Well, $keyword is never used again, so I think this would be a little more straight forward:code:
code:
code:
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 |
|
It can be further reduced to this. Yes, it should work. I think. Erk, been too long.code:
|
# ? Jun 11, 2009 08:42 |
|
code:
|
# ? Jun 11, 2009 11:04 |
|
McGlockenshire posted:It can be further reduced to this. Yes, it should work. I think. Erk, been too long. The best trolls are the ones that aren't obvious. gently caress your brace stripping ways
|
# ? Jun 11, 2009 19:04 |
|
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!
|
# ? Jun 11, 2009 20:29 |
|
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 |
|
PHP is, though.
|
# ? Jun 11, 2009 22:51 |
|
Found this in a Perl script todaycode:
|
# ? Jun 11, 2009 23:40 |
|
Lexical Unit posted:Found this in a Perl script today I should hope there wasn't
|
# ? Jun 11, 2009 23:42 |
|
Yeah because it wouldn't run if it had it 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 |
|
Maybe someone was too lazy to comment out the entire if structure.
|
# ? Jun 12, 2009 02:10 |
|
That was surely their intention, but w/o use strict the bare text false becomes a string literal which evaluates to true
|
# ? Jun 12, 2009 03:27 |
|
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 |
|
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?
|
# ? Jun 12, 2009 08:21 |
|
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 |
|
This* is why warnings and strict should have defaulted to on since like 1995 *among many other things
|
# ? Jun 12, 2009 17:26 |
|
Nope, sorry, don't wanna break backwards-compatibility with all of the high-quality software that depends on barewords
|
# ? Jun 12, 2009 17:42 |
|
Otto Skorzeny posted:This* is why warnings and strict should have defaulted to on since like 1995 Ummmmm gently caress you buddy? Barewords are a great way of cutting out a few keystrokes in Perl Golf.
|
# ? Jun 12, 2009 17:58 |
|
code:
|
# ? Jun 13, 2009 18:41 |
|
implicit posted:
Wow, very descriptive variable names! It's like you don't even need comments, it just explains itself
|
# ? Jun 13, 2009 20:09 |
|
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:
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:
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 |
|
code:
|
# ? Jun 15, 2009 18:10 |
|
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. code:
|
# ? Jun 15, 2009 19:15 |
|
sort {$a+=$b} @list;
|
# ? Jun 16, 2009 01:29 |
|
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 |
|
Otto Skorzeny posted:This* is why warnings and strict should have defaulted to on since like 1995 (USER WAS PUT ON PROBATION FOR THIS POST)
|
# ? Jun 16, 2009 02:06 |
|
|
# ? May 15, 2024 02:25 |
|
http://codytaylor.org/?p=14122
|
# ? Jun 16, 2009 04:08 |