<?xml version="1.0" encoding="windows-1252"?>
<node id="233940" title="Re: Re: (nrd) Quality Perl/CGI programs?" created="2003-02-09 14:25:56" updated="2004-08-22 09:52:57">
<type id="11">
note</type>
<author id="6211">
coolmichael</author>
<data>
<field name="doctext">
I sat through a code review a few months ago. It was my first time, and quite the experience. The person's CGI script started just like yours does above. Then, about thirty or so lines in, there was
&lt;code&gt;
$filename =~ m/(.*)/gi;
$filename = $1;
open FILE, "$filename";
&lt;/code&gt;

I was shocked, as this was code written by a "professional."  I can count about six errors in those three lines of code.&lt;p&gt;
&lt;ol&gt;
&lt;li&gt; Poor taint checking (none really.)
&lt;li&gt; Not checking if the match succeeds. I guess it doesn't matter if it's just matching [deat to dot star|dot star].
&lt;li&gt; Not checking if the open succeeds.
&lt;li&gt; Should use the three form of open 
&lt;li&gt; The match is stupid. dot-star doesn't care about case insensitivity (/i).
&lt;li&gt; The match is really stupid. /g is (i think) for trying to match multiple times in a loop. This doesn't do that.
&lt;/ol&gt;
&lt;p&gt;You are quite right, warnings, strict, CGI, and taint are a good start. But you do need to still read the code before you use it. I don't think there is anything to help avoid a good code review.
&lt;p&gt;
&lt;b&gt;update&lt;/b&gt;: The programmer still works there. I don't, by my own choice.&lt;/p&gt;
--&lt;br&gt;
&lt;a href="www.negativespace.net"&gt;negativespace.net&lt;/a&gt; - all things inbetween.</field>
<field name="root_node">
233900</field>
<field name="parent_node">
233936</field>
</data>
</node>
