Look at something you wrote at least six months ago (i.e., something you haven't looked at in at least six months), and see whether you can understand it. If it didn't include "use strict", make a copy, add "use strict" to it, and see how long it takes to make it work like the original.

If it had "use strict", but not "use warnings" (or "-w" on the shebang line), add that as well, and see (1) how many warnings you get, and (2) how long it takes to make them all go away (while still making it work like the original -- assuming the original was doing the right thing ;^).

Look for repeat occurrences of:

• The same quoted string (or many strings that all have some common substring)
• The same "if" condition
• The same sequence of steps in different loops or subs or sections of the main code (with just some differences in the literal values or variables being used)

(If your code already has "strict" and "warnings", post a snippet of it here, and see how people react to it.)

As for "good functionality", that's what we call "an empirical question" (i.e. testable): does it do what it is supposed to do, or not? You could change the question slightly, to "does it do its job effeciently?" but this isn't always relevant. In general, if it does the job without a lot of unnecessary steps, that should suffice.

As for points to pay attention to, the most important one is documentation! Write a coherent, human-readable description of what a program is supposed to do (what are its inputs and outputs, what goals does it accomplish, and -- briefly, succinctly -- how does it work), and do that first . Then write the actual code, in accordance with the description. Keep the description in the same file with the code, in pod format.