in reply to IYHO, what do you consider good code?

Iím not sure, being a young monk myself, if I possess much experience and wisdom to give, so youíll have to forgive me if what I am about to say was not the advice you were looking for.

Good code to me is code that uses warnings and uses strict, so that you can be warned about problems with your code and prevent your program from accidentally doing something very "silly". I always write my code so that if someone else were to read it, they would understand what I have done and why I have done it by using internal commentary, and using whitespace to make it readable. (Or, if you have as bad a memory as I do, be able to come back to the code 3 weeks afterwards and still be able to see without much contemplation and frustration why you wrote it that way in the first place). My mind is split on the subject of modules; on the one hand I would encourage their use, especially when you are starting to learn Perl, but I think it does make a good programming exercise to see what way you would do it, and compare that with the module and see what could be improved. You never know, you may invent a better wheel.

As far as learning to code "well" is concerned, the only advice I can give, which would I feel would be more useful to you than myself or others setting down restricting guidelines to follow (and sometimes, as Ovid points out, it is better sometimes to break them if you know why you're breaking them), is to read code and write code. The Perl Monastery has many able programmers who are quite happy to offer criticism for code (your scratchpad is very useful for this), and will be more than willing to help and give you feedback on programs or snippets. It will take time and perseverance (you cannot become a good Perl programmer in 24 hours, or 21 days, or however long the books claim nowadays), and I know that it can be hard at first to accept criticism, however well-intended and constructive the advice may be, for code that you have worked for hours upon and were quite happy with until five minutes ago when $monk pointed out that it could be improved here, here, here and here, but in the end you will be better coder for it. Keep a directory of all the code you have written somewhere, and as you learn new things come back to them, ask yourself what ways they can be improved, what are the other ways you could use to solve this problem?

I hope this has answered some of your questions, and I hope to see you around.

rozallin j. thompson
The Webmistress who doesn't hesitate to use strict;