Re^2: writing after parsing

Hello thanos1983, since you've indicated that you're still learning, here are a few more suggestions:

Although it might work, I'd again suggest not to use $_ as much as you are. For example, inside your sub extra, you're using it for at least two different things; it'd be much easier to keep track of this if you used named lexical variables instead, e.g. my $filename and my $line. $_ is fine for short pieces of code, but using it over long spans can cause problems later on when you or someone else attempts to read and modify the code.
Style: Intermixing sub declarations with code makes the program flow a little hard to follow. Usually, one would put all the subs at the bottom of the file, with all the other code above.
Design: Perhaps the program structure might be more clear if you split extra into two subs, one for reading the XLS and one for writing the CSV? Also, writing CSV is much better with Text::CSV.
Style: Proper indentation helps the reader. See also perltidy.

Keep up the good work learning, and the effort you are putting into your responses is admirable. (Just please make sure they stay correct, and/or are marked as "I'm still learning", so other people learning can benefit from them as much as you are.)

Comment on Re^2: writing after parsing Select or Download Code

Replies are listed 'Best First'.
Re^3: writing after parsing by thanos1983 (Parson) on Aug 10, 2014 at 12:43 UTC
Hello Anonymous Monk, That is true I am over using the parameters ($_,@_) because I found them so useful and to be 100% honest I thought they operate faster than defining a new parameter (e.g. my $line). But as I said I am still learning and to be honest I am trying to reach and provide comments in most questions that I can. The reasons are two, firstly people more experienced than me can also comment on top of my comments so I can learn from them, secondly I think that more experienced people tend to forget how was it back when "they where new to programming" and usually provide a straight answer to the problem. I found my self feeling a bit wrong about it because apart from a solution to the problem it would be nice the user to actually now and understand why this is happening and why I should write my code like this. Well to be even more honest I am only coding almost 2 years, and I have been working with a variety of programming languages so I am not specialized in all of them. When I start working more with Perl I got impressed with the abilities. So now I am learning and trying to get my hands "dirty" as much as possible to be able to assist people with my long comments and answers. :D I took in consideration your comments from the question but when I finished this code was 2 days before. I was looking forward to improve the user input using see question-2. I am still working with it trying to pass it through an OO process. So I did not spend time to modify this code. I wanted to provide a sample of solution to the user so he can start working with it, because I have a few ideas to push the code more before stop working with it. But because it might take more time I did not modify it. Any way I have already wrote too much, thank you again for your assistance to my questions I hope that I will get better soon. ;) I am recent graduate and looking forward to get a job in the telecommunication where I will get new challenges to learn and modify my skills even further. Seeking for Perl wisdom...on the process...not there...yet!	[reply] [d/l]
Re^4: writing after parsing by Anonymous Monk on Aug 10, 2014 at 17:36 UTC
Yes, writing a lot of (well documented) code and continually improving it is a great way to learn! I am over using the parameters ($_,@_) because ... I thought they operate faster My suggestion would be: don't worry about speed until it becomes an issue. Saving a few milliseconds execution time is only sometimes important, but a lot of the time code readability and maintainability is more important. When writing, one should of course take care not to brute-force everything (like for example knowing to use a hash instead of grepping over an array where appropriate, or not reading a second input file once for every line of the main input, like two recent posts here), but as they say, premature optimization is the root of all evil. If the execution speed of a program does become an issue, then one can profile the code and optimize the places where it's actually slow. I am recent graduate and looking forward to get a job in the telecommunication http://jobs.perl.org ;-)	[reply]