There's a lot of repetitive content in your code (many identical copies of statements), and in your case, this is an especially bad thing, because (1) the code is formatted in a manner that is virtually illegible to humans, making it hard to tell whether repetitions are exact, and (2) the repeated lines are often long and complicated, so that if you need to make a change -- and the change will have to be repeated on every copy of the affected line -- it will drive you crazy and you will find it really hard to avoid mistakes.

For example, if you modify your "read_outpath()" subroutine to handle the "file not found" condition, you'll need only one copy of your "default value" for $data, instead of four copies (and the code will be a lot easier for human readers to understand): 

sub read_outpath {
    if ( open FILE, '<', $outpath ) {
        read FILE, $data, 100000000;
        close FILE;
        return 1;
    }
    else {
        $data = <<EOT;
<html>
 <head><title>ISSUE REPORT<\/title><\/head>
 <body bgcolor="#CCFFCC"><h1 align="center">MISMATCH REPORT</h1>
 <table width="1200px" border="10" align="center" frame="border" rules
+="all">
  <thead><tr bgcolor="#FFCCFF">
  <th>ARTICLE ID</th><th>FILE MISSING IN PATH</th>
  <th>S100 OUTPUT</th><th>F300 OUTPUT</th>
  <th>DIFFERENCES</th></tr></thead>
  <tbody></tbody>
 </table>
 </body>
</html>
EOT
    }
    return 0;
}

[download]
That's one of many cases where a some more thought about the task and the conditions can lead the elimination of repeated code, which in turn leads to easier maintenance and legibility.

One other very important problem here: lack of documentation, especially about what the command-line args are supposed to be. You're logic implies some very strange expectations about what goes into @ARGV, and you really should provide at least a SYNOPSIS of the usage. It would be even better if you provide a DESCRIPTION of what the program is supposed to do, maybe even explaining the various conditions that it handles.

If you can describe the program's logic (i.e. document it) in a clear, concise way, it's likely you'll find it easier to write clear, concise code to implement that logic, getting rid of a lot of useless and redundant chunks of ugly stuff.

In reply to Re: code for review by graff
in thread code for review by basheer

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.