Replies are listed 'Best First'.
RE: Thoughts from a newbie
by chromatic (Archbishop) on Oct 05, 2000 at 04:11 UTC
    Predeclaring arrays isn't generally necessary -- there's a bit of a performance benefit as dynamic memory allocation isn't necessary, but Perl handles that sanely anyway.

    Caveats aside, save a few characters: my @x = ( 0 ) x 25;

    This construct could also be more concise:

    while(defined(my $line = <FILE>)) { next if ($line =~ /#.*?,/); my @units=split(/,/, $line); for ($i = 0; $i <= 23; $i++) { if ($line =~ /$xcounits[$i]/) { $y[$i]++; $ytot++; $x[$i] += $units[5]; $xtot += $units[5]; } } }
    The defined is in there just in case. (I believe the magic <FH> read does this for you, but I don't have time to look up to make sure assigning to a variable explicitly does.)

    The regex could be less cautious. If you want to skip comments, it's a lot easier just to do next if $line =~ /^#/;.

    The loop there makes me wonder if you're better off with a hash. Anytime you find yourself looping through an array, looking for a particular element, you should ask if a hash would be more appropriate.

    Looks like your next hurdle is learning some Perl idioms to make your life easier. Don't worry, they make more sense once you use them a few times.

    Update: moen is right, so I fixed that little issue. Thanks!

      Shouldn't that be
      my @x = (0) x 25;
      Else they all end up in the first element of the array :)
RE: Thoughts from a newbie
by clemburg (Curate) on Oct 05, 2000 at 12:16 UTC

    If you want people to comment on your code, and you want to receive tested code back, please provide some test data for your script - it's hard for people to guess your input data.

    Some things I noticed:

    • Why do you open a specific file in the script (with hardcoded pathnames)? Why not just make the script a filter and read from STDIN, and pipe the file (e.g. with "cat" under UNIX, or "type" under Win32) onto the script? That way you won't have to change the script when the location of your data changes.
    • You should not hardcode the "23" in the for loop - that should be "@xcounits" (which will yield the number of entries in the array because of scalar context). Neither should you hardcode the "5" and the "0" in the references to "@unit".
    • The structure of your indentation looks weird to me - but that's a matter of taste, too. Anyway, I think you should indent the body of "coreport()".

    Christian Lemburg
    Brainbench MVP for Perl
    http://www.brainbench.com

      In the case of the for loop you are correct but, for the @units references I want *that* specific array element each time, and the format does not change. How would I get around that?

      gods restored content based on following comment.

        You said: "In the case of the for loop you are correct but, for the @units references I want *that* specific array element each time, and the format does not change. How would I get around that?"

        You could at least use a variable instead of the number "5", and give it a speaking name. Hardcoded numbers are a Bad Thing. You should probably search for all other numbers than "1" or "0" in your scripts and replace them by variables.

        If you are interested in good programming style, please do yourself a favor and read one or more of these books:

        • Code Complete. A Practical Handbook of Software Construction. Steve McConnell. Microsoft Press, 1993. See, there are good things coming from Microsoft ;-). Really a classic, this book is the best reference on small-scale development processes I have read till now. Very solid and balanced advice. A great section on naming conventions. Very good discussions on various coding issues, with good literature pointers for further reading. Some people will tell you this is outdated, but this is wrong.
        • The Elements of Programing Style. 2nd Ed. Kernighan and Plaugher. McGraw-Hill, 1978. Very good tutorial on coding practices. Rather dated by now, and incovenient to read because of its use of Fortran and PL/1 as example languages. On the other hand, the lessons still apply to any of the more modern languages, and the book is rather cheap, so it's still nice to have.
        • The Practice of Programming. Brian W. Kernighan and Rob Pike. Addison-Wesley, 1999. A worthy successor to The Elements of Programming Style. Very readable, and a good treatment of many basic issues in professional programming.

        Christian Lemburg
        Brainbench MVP for Perl
        http://www.brainbench.com