Search code examples
perlmaintainability

What makes Perl code maintainable?

I've been writing Perl for several years now and it is my preferred language for text processing (many of the genetics/genomics problems I work on are easily reduced to text processing problems). Perl as a language can be very forgiving, and it's possible to write very poor, but functional, code in Perl. Just the other day, my friend said he calls Perl a write-only language: write it once, understand it once, and never ever try to go back and fix it after it's finished.

While I have definitely been guilty of writing bad scripts at times, I feel like I have also written some very clear and maintainable code in Perl. However, if someone asked me what makes the code clear and maintainable, I wouldn't be able to give a confident answer.

What makes Perl code maintainable? Or maybe a better question is what makes Perl code hard to maintain? Let's assume I'm not the only one that will be maintaining the code, and that the other contributors, like me, are not professional Perl programmers but scientists with programming experience.

Solution

  • What makes Perl code unmaintainable? Pretty much anything that makes any other program unmaintainable. Assuming anything other than a short script intended to carry out a well defined task, these are:

    • Global variables
    • Lack of separation of concerns: Monolithic scripts
    • NOT using self-documenting identifiers (variable names and method names). E.g. you should know what a variable's purpose is from its name. $c bad. $count better. $token_count good.
      • Spell identifiers out. Program size is no longer of paramount concern.
      • A subroutine or method called doWork doesn't say anything
      • Make it easy to find the source of symbols from another package. Either use explicit package prefix, or explicitly import every symbol used via use MyModule qw(list of imports).
    • Perl-specific:
      • Over-reliance on short-cuts and obscure builtin variables
      • Abuse of subroutine prototypes
      • not using strict and not using warnings
    • Reinventing the wheel rather than using established libraries
    • Not using a consistent indentation style
    • Not using horizontal and vertical white space to guide the reader

    etc etc etc.

    Basically, if you think Perl is -f>@+?*<.-&'_:$#/%!, and you aspire to write stuff like that in production code, then, yeah, you'll have problems.

    People tend to confuse stuff Perl programmers do for fun (e.g., JAPHs, golf etc) with what good Perl programs are supposed to look like.

    I am still unclear on how they are able to separate in their minds code written for IOCCC from maintainable C.