Re^4: Developing code to be a module (perl -lanse)

in reply to Re^3: Developing code to be a module (perl -lanse)
in thread Developing code to be a module

I don't have a problem with "Perl Golf" short solutions ...:-)

There is nothing even remotely "Perl Golf" about that, IMHO that is practically a slur against perl, practically anti-perl-propaganda :)

However its obvious the OP (Original Poster) is not talking about those basic sorts of problems.

Sure its not :) Take for example Watching long processes through CGI (Aug 02), nothing particularly basic about it, sure its got 2 functions, but most of the code isn't in functions, less than 100 lines

Or take for example Text-CSV_XS-0.97/examples/csv2xls, 200 lines, one function( usage(), mostly string/heredoc)

Its easy to well past 1000 lines with this type of program, and its obvious to me this is the type of program the OP is talking about -- doesn't need modules or Test:: anything

Comment on Re^4: Developing code to be a module (perl -lanse)

Replies are listed 'Best First'.
Re^5: Developing code to be a module (perl -lanse) by space_monk (Chaplain) on May 01, 2013 at 08:39 UTC
Whilst the example you linked to doesn't use Test:: anything, your argument is somewhat deflated by the fact that that Text::CSV_XS has extensive unit tests attached to it, according to the Manifest you linked to. :-). I haven't time to examine the example you referred to in detail, so I could be wrong, but I suspect there is a case to be made for contents of the main loop to be also made into a function. Personally I'm deeply uncomfortable if someone has waffled on for 1000 lines of programming without breaking it up somehow! But I won't deny that there will always be exceptions to this principle, e.g. large tables of necessary data, text or whatever. If you spot any bugs in my solutions, it's because I've deliberately left them in as an exercise for the reader! :-)	[reply]
Re^6: Developing code to be a module (perl -lanse) by Anonymous Monk on May 01, 2013 at 09:08 UTC
Whilst the example you linked to doesn't use Test:: anything, your argument is somewhat deflated by the fact that that Text::CSV_XS has extensive unit tests attached to it, according to the Manifest you linked to. :-). Sure its not :) None of those unit-tests cover/check csv2xls, a human does that I haven't time to examine the example you referred to in detail, so I could be wrong, but I suspect there is a case to be made for contents of the main loop to be also made into a function. Sure there is, if you want to make it into a module, like the OP describes. But as a stand alone program, its perfectly serviceable without being a function -- and has been since Text-CSV_XS-0.26 in 2007 Personally I'm deeply uncomfortable if someone has waffled on for 1000 lines of programming without breaking it up somehow! I learned about it from those pythong folks, they call it whitespace, I hear it can work for anyone :) :D	[reply]
Re^7: Developing code to be a module (perl -lanse) by space_monk (Chaplain) on May 01, 2013 at 16:51 UTC
The item of code you have quoted is what is known as an example; if it were used in a professional environment you would write a unit test for it. Unit tests have a purpose; if someone comes along to improve the code, then they can verify that their changes do not screw it up in any way. If you spot any bugs in my solutions, it's because I've deliberately left them in as an exercise for the reader! :-)	[reply]
Re^8: Developing code to be a module (professionalism) by Anonymous Monk on May 02, 2013 at 04:06 UTC

In Section Seekers of Perl Wisdom