Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change

Re (tilly) 1: Certification Foo

by tilly (Archbishop)
on Jan 25, 2002 at 21:59 UTC ( [id://141564] : note . print w/replies, xml ) Need Help??

in reply to Certification Foo

As someone who has been known to venture his opinions on maintainability, I think this dream exam is impossible to make work for various useful values of work.

The problem is that maintainability is not inherent in the code. Instead it is an interaction between the code and the maintainance programmer.

For reasons I hint at in nodes like Re (tilly) 1: Compactness, one of the characteristics of highly maintainable code is that it does a good job of maximizing the understanding the programmer gets for time spent studying the code. This is very different than maximizing functionality per character. For instance it is far more important to make it as easy as possible to chunk concepts together into higher level constructs, with which you can express your solution very naturally. And, of course, you would like to name and document your chunks suggestively so that the maintainance programmer can learn to use the chunks you are working with without having to go through all of the details.)

However note that this description is highly dependent upon the programmer. Using powerful constructs like map can make it very hard for someone who knows only a little Perl to figure out what is going on, while causing no trouble for the experienced Perl programmer. Experienced programmers immediately chunk idioms upon sight, while less experienced ones don't know and don't care that something is a common idiom. Competent programmers generally have far more tolerance for having ideas rapidly build on each other than average ones or novices. (Code meant to be read by non-programmer, eg configuration files, should not be organized like you would for a fellow programmer.) There are many different styles of programming and you chunk in each in a different way. For instance OO and functional styles pose problems for people who are not experienced in them, even while they simplify life for people who are familiar with the style.

And so on.

In short, the maintainability of code is not something that exists in the abstract. Sure, code can be (and often is) clearly bad. But in general there isn't really such a thing as clearly maintainable code. The maintainability of code is defined through interaction with your audience, and the audience of possible Perl programmers is too diverse to be readily characterized.