Tom Yarrish am Montag, 28. November 2005 05.33: > Hey all, > I've been reading this list for a while, and I've been trying to > learn perl on my own for quite some time. However, my job doesn't > really (from my vantage point at least) "allow" me to do any sort of > programming (by that I mean my day to day work is more administrative > and project related versus writing any code). So it makes it > difficult for me to apply what I've read from the O'Reilly books to > real world problems (and I've read the Llama book a few times). > My main issue has been trying to come up with a way to build up any > type of perl skills, and I know to do that requires writing code. > However it's been difficult for me to come up with something to > write. Some of the things I think about doing are too far ahead of > my skill set, and I want to have a better understanding of > fundamentals before I take on larger "programming projects." I tend > to be more of a "hands on" type of person, so as I do things more and > more, I understand how it works. > So I was curious as to what some of the more experienced perl mongers > out there have done to improve their Perl skills past reading the > standard books. Do you go to some sites and improve code? Do you > just sit around and think up something to program? > How do you improve your skills, if you're not programming "every day"?
This is not an answer to how to improve perl skills, but an answer how to make it easier to maintain your code with improving perl skills. I know, you didn't ask for that... [*] Modularise your code. If a big problem can be split into smaller parts, code accordingly: Use subs and modules. This will make maintenance easier. perldoc perlmod [*] Ask "Can I generalize the specific task a want to program?" If possible, do it and create a module for it. This means more work now, but lesser work later. It is also a motivation to think deeper about the task. And, chances are there that you can reuse the module. (This avoids, after detecting errors, to fix them in widespread cut&pasted code) When designing a module, keep your eyes on the public interface. Don't choose the interface based on the easiest implementation. It's easier to change/improve the implementation than the interface if a module is in use. And don't forget - to comment your code - to sanitize any input from outside from the beginning on - to develop tests parallel to the code - to have a look into the perl source to get ideas - before reinventing wheels, look for modules on search.cpan.org If you have enough time, reinvent wheels - but then, use the existent wheels, and compare them with yours. I certainly missed some points :-) joe -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
