Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Re^8: bug or curly bracket hell?

by MoodyDreams999 (Beadle)
on Jan 25, 2023 at 15:04 UTC ( [id://11149874]=note: print w/replies, xml ) Need Help??


in reply to Re^7: bug or curly bracket hell?
in thread bug or curly bracket hell?

Yeah, I apologize I'm a noob and still getting better at optimizing and minimizing my code, wasn't really sure how else to cut it down.

Replies are listed 'Best First'.
Re^9: bug or curly bracket hell?
by kcott (Archbishop) on Jan 25, 2023 at 21:51 UTC
    "Yeah, I apologize I'm a noob ..."

    None of us left the womb with knowledge of Perl. We all had to learn and practice it. This is not something for which you need to apologise.

    "... and still getting better at optimizing ..."

    Code optimisation is the last thing you should be doing. Don't even concern yourself with it at this stage. The most important thing is to get the program to run correctly; i.e. produces expected results without errors or warnings.

    If, when running correctly, you find it is running exceptionally slowly, or chewing up vast amounts of memory, or something similar, that's the time to look at optimisation. There are hints in "perlperf - Perl Performance and Optimization Techniques" but, as I said, this is the last thing to address. You can ask us about optimisation, in a separate question, if you're having problems in this area.

    "... and minimizing my code, wasn't really sure how else to cut it down."

    Perl doesn't care how long or short your code is. As a general rule, aim for readability, not brevity. There are benefits to following the DRY principle; however, at this stage, getting your code to work correctly is more important.

    I don't know how you managed to end up with the code you posted in "Re^4: bug or curly bracket hell?". Instead of reaching for a search engine to fix problems, you should calmly and carefully look at what you've written. I'm pretty sure that if you'd done that, the 'print "' at the start would have alerted you to a problem.

    Perl's diagnostic messages are described in perldiag. This is the place to look for an explanation of error and warning messages. Search for key phrases in the messages; specifics are typically replaced with '%s'; so, as an example, you'd need to look for 'Argument "%s" isn't numeric%s'. Until you're familiar with this, such a search can be tricky; while learning, I suggest you use the diagnostics pragma BUT do remove this from production code (it's only intended to be used as a developer tool).

    I recommend that you take a step back and read "perlintro - a brief introduction and overview of Perl". This will take you through the basics: it explains not just what to do but also why you should do it. Every section here is peppered with links to more detailed information: you won't need to follow all of these now, but you'll find them useful over time; bookmark this link for future reference, it's an excellent resource.

    I don't intend to provide a full code review; however, you're I/O handling has many problems. Here's some guidelines:

    • Read the documentation for the open() function.
    • Use lexical filehandles (e.g. my $conf_fh) not package variables (e.g. 'conf' and FH).
    • Always use the 3-argument form of open().
    • Use the autodie pragma and let Perl handle your I/O exceptions. Hand-crafting your own messages is tedious and error-prone; and things like "... or die;" are pretty much useless.

    Putting all of that advice together, your typical script might start something like this:

    #!/usr/bin/env perl use strict; use warnings; use diagnostics; # TODO - remove in production use autodie;

    When posting questions, please remove all of the unnecessary parts. For instance, can you show the problem using a spreadsheet with two columns (e.g. first and last name); does address, post code, phone number, etc. add anything useful in terms of describing the problem. See SSCCE for a discussion of this. When presented with screenfuls of code, many monks (who could potentially provide you with excellent advice) may decide that that do not have time to deal with something so large: this is your loss.

    — Ken

      Perl doesn't care how long or short your code is. As a general rule, aim for readability, not brevity.

      From long experience, and especially from several years of writing medical and aerospace software: Optimize your code for readability, because most of the time, you will READ your (or someone else's) code. And more often than you will like, you will have to read old, ugly code from people who wanted to outsmart compiler and/or coworkers. And the worst code will be your own old code.

      Alexander

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
Re^9: bug or curly bracket hell?
by Anonymous Monk on Jan 25, 2023 at 16:58 UTC
    There are 2 things you should be doing to make the code easier to understand and maintain. #1 is the logical use of blank lines to separate different concepts and proceses.

    Illogical spacing:

    open('conf', "$PATHconf") || die "can't open $PATHconf: $!\n"; my @conf = <conf>; close('conf'); my $i=0; foreach(@conf){ my $line = $conf[$i]; my $t= "".$i; my $dbhA = DBI->connect("DBI:mysql:$VARDB_database:$VARDB_server:$ +VARDB_port", "$VARDB_user", "$VARDB_pass") or die "Couldn't connect to database: " . DBI->errstr; my $rowCount = 0; my $filename = "Output012023.xlsx"; my $workbook = Excel::Writer::XLSX->new( $filename ); open(FH, "<", "Debt.csv" ) or die;
    Logical spacing:
    open('conf', "$PATHconf") || die "can't open $PATHconf: $!\n"; my @conf = <conf>; close('conf'); my $i=0; foreach(@conf){ my $line = $conf[$i]; my $t = "".$i; my $dbhA = DBI->connect("DBI:mysql:$VARDB_database:$VARDB_server:$ +VARDB_port", "$VARDB_user", "$VARDB_pass") or die "Couldn't connect to database: " . DBI->errstr; my $rowCount = 0; my $filename = "Output012023.xlsx"; my $workbook = Excel::Writer::XLSX->new( $filename ); open(FH, "<", "Debt.csv" ) or die;
    #2 is to add a comment every time you figure something out:
    foreach(@conf){ my $line = $conf[$i]; # the reason for doing this weird thing my $t. = "".$i;
    The comments will significantly reduce the cognitive load needed to comprehend the code by outsourcing all the reasons for this and that to brief human readable comments.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11149874]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others chilling in the Monastery: (3)
As of 2024-03-19 05:11 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found