Mad, bad and dangerous to know

There always seems to be a background of chatter about how Perl makes it easy to create bad programs, and quite honestly I've never really dissented from that view: there is a lot of horrible, insecure and badly written code out there.

However inspired by Bugle I thought it might be interesting to see just how much bad stuff there really is. Of course there is always the "low hanging fruit" of code using horrid cut and pasted parameter parsing which always contain so many other ~~lovely~~ bugs. Then I turned to passing unchecked form input as a header to a mail program. Eugh. Passing unchecked input to system anyone? Anyway I wanted to try something like "open OUT ">$In"" filetype:pl to try for unchecked input being passed to open but it made too many false positives

Anyway I got bored at that point, however I thought it would be amusing to set you lot on it to see if we could come up with some examples of searches that are guaranteed to throw up the most egregious Perl code on the web.

To it!

/J\

Comment on Mad, bad and dangerous to know Select or Download Code

Replies are listed 'Best First'.
Re: Mad, bad and dangerous to know by eXile (Priest) on Jul 29, 2006 at 14:32 UTC
"Matt's Script Archive" -"nms" filetype:pl ? or leaving 'fatalstobrowser' in your production CGI.pm code ?	[reply]
Re^2: Mad, bad and dangerous to know by Herkum (Parson) on Jul 30, 2006 at 13:44 UTC
As much as everyone complains about how bad "Matt's Scripts" are, I don't think they are that bad. At the very least they have, Documentation and notes near the code describing what it is supposed to do Its neat, easy to read. I seen worse, the guy whose code that I took over in my last position had a 500 line if-elsif-else loop. No notes, no documentation, and a lot of it went beyond 100 characters per line (so I cannot even print it out to make it readable). That is BAD PERL CODE. I will take the examples you gave over the stuff I had to maintain anyday!	[reply]
Re^3: Mad, bad and dangerous to know by davorg (Chancellor) on Jul 31, 2006 at 15:29 UTC
Do you really think that Matt's code is easy to read? I think it looks horrible. It's massively overcomplicated, it's full of outdated Perl 4 idioms and it doesn't make any use of modules which would reduce it in length by about a half. But my biggest problem with it is the number of people who have written other bad code following Matt's example. I'd guess that at least half of the broken, hand-coded CGI parsers that I see are based on Matt's code. Update: It's also worth noting that whilst the latest version of Matt's formmail is (as far as I can see) free from security holes, older versions that are famously insecure are still in use on hundreds of web servers. I know that the nms versions of the program are more secure and better written. I hope that they are also easier to read. -- <http://dave.org.uk> "The first rule of Perl club is you do not talk about Perl club." -- Chip Salzenberg	[reply]
Re^4: Mad, bad and dangerous to know by gellyfish (Monsignor) on Jul 31, 2006 at 15:33 UTC
Re^3: Mad, bad and dangerous to know by Hofmator (Curate) on Jul 31, 2006 at 07:22 UTC
No notes, no documentation, and a lot of it went beyond 100 characters per line (so I cannot even print it out to make it readable). In such a case, maybe Perltidy (external link) might be helpful ... -- Hofmator	[reply]
Re^4: Mad, bad and dangerous to know by Herkum (Parson) on Jul 31, 2006 at 12:56 UTC
Re^3: Mad, bad and dangerous to know by Anonymous Monk on Jul 31, 2006 at 19:51 UTC
I seen worse, the guy whose code that I took over in my last position had a 500 line if-elsif-else loop. No notes, no documentation, and a lot of it went beyond 100 characters per line (so I cannot even print it out to make it readable). That is BAD PERL CODE. A lot of perl code is bad perl code. I've seen 500+ line loops in about 30% of the perl code I see. The lack of use strict is worse. No one writes tests; unit or otherwise. Documentation is restricted to crypic comments in the source than often guard against conditions that no longer apply, or are flat out wrong. It's easy to blame the coders, but management let it into production in that state...	[reply]
Re: Mad, bad and dangerous to know by aufflick (Deacon) on Aug 02, 2006 at 00:26 UTC
There are not often Perl examples, but The Daily WTF is always good for a laugh (or cry). Brillant!	[reply]
Re: Mad, bad and dangerous to know by gawatkins (Monsignor) on Aug 02, 2006 at 12:14 UTC
Fortunately/Unfortunately the bad code can't be contained to Perl, As a Systems Admin, I have had the pleasure of troubleshooting code created by untrained "coders". One such example was by a "scheduler" that defaulted into a reporting role because he had the most Access 97 of anyone on that team. Most of the code was simply cut and pasted from the web, with the original formatting and comments included. After he went on to a different company, several of us spent months combing through the code to clean it up. Thank you, Greg W	[reply]
Re: Mad, bad and dangerous to know by gellyfish (Monsignor) on Oct 06, 2006 at 18:20 UTC
This is made all the more interesting by Google's introduction of Code Search: it looks into archive files, does regular expression searches and everything :-) /J\	[reply]

Back to Meditations