|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:
Putting all of that advice together, your typical script might start something like this:
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.
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.
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
#2 is to add a comment every time you figure something out:
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.