Without programming principles
andi | 2006/12/12The other day I’ve yanked out a little perl script to perform a dull maintenance task. It was perl programming at it’s best.
While designing this little script I deliberately ignored some good programming practices. No subroutines, nothing for the use(r) convenience was planned in. So the code now sports some doublets and some very inefficient functional parts.
Nevertheless, I’m very happy with this tool. First, it’s well documented. Both in the sense that the code is easy to read and with an extensive source code documentation (20% code/documentation ratio). Since such tools tend to live much longer than originally anticipated, they are much more often read than re-written, hence clarity is an essential design feature.
Second, the tool is a well of copy-and-paste opportunities. Leaving out all the fancy things makes the code highly portable across different versions or even different programming languages. Here again, duplication of code is meant to be a feature, not a flaw. With every part of the code being independent, many sources of errors are kept out: no subroutines can be forgotten, nothing implicitly hidden in other parts of the code.
Finally, the major benefit is that the tool is finished and complete in itself. All the requirements have been fulfilled without any overhead and the danger of feature creep is mitigated by the fact that almost any feature change comes at the cost of a complete rewrite. On the other hand, ease of maintenance is guaranteed by the simple layout paired with the emphasis on documentation. (And the fact that the parts that have been duplicated are just for housekeeping or linked directly to the core data structure.)
So for small tools, it’s fine to throw some programming principles overboard, if the time is spent on documentation.
[...] fully agree. And hence, I should turn my little script from my past article into a tool. But isn’t it already one? — Both authors fail to give a definition of what [...]