in reply to Meaning of Maintanability and Functionality in Coding Perl
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:
(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.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: Meaning of Maintanability and Functionality in Coding Perl
by pg (Canon) on Oct 18, 2005 at 06:01 UTC |