tchrist has asked for the wisdom of the Perl Monks concerning the following question:
Whenever anything anywhere goes wrong in this code base, or if it needs enhancement, or if it simply needs explaining to people who don’t understand Perl very well, I’m the wizard-in-residence who gets tapped to explain what’s really going on and how one might go about enchancing, revising, fixing, or refactoring the old code.
Some of this code is as robust and sophisticated as the best of CPAN, written with a modular, testable, and often object-oriented design. But most of it is not. Much of it is written by very recent college graduates with no formal Perl training who just copied existing code without understanding it, making tiny tweaks along the way. So you see the same bad memes spread like a virus. Think of the bad old “script-kiddy” days of the very start of all the Perl CGI code people were writing back in the early 90s, and you’ll have a pretty good idea of what this code looks like. It is . . . astounding.
One enormous problem is that the code is written very un-idiomatically — even anti-idiomatically — as far as Perl norms are concerned. Often it looks like they’re writing a gigantic shell script or sometimes an ugly C program. They aren’t always very experienced with Unix, so something like the proper care and feeding of errno with all its vicissitudes and caveats completely eludes them, and process-management with fork, waitpid, pipes, and the correct 16-bit handling of $? is often missed.
The worst problem of all seems to be that they don’t have any experience in being able to recognize what natural, idiomatic, and maintainable Perl code even looks like in the first place. They are just not familiar with standard Perl idioms. So you see them doing strange things like foreach(<INPUT>), or resorting to character-by-character processing of strings using index and substr instead of using regexes. Almost all their data structures are flat arrays or hashes, nothing multilevel, and there are no structure/records to speak of. It’s at best Perl4ish.
But some are really very helpful. I especially like the ones involving complexity metrics, both the McCabe stuff and the rest of it.
Some of those are of course conflicting, especially in the Efficiency section. But many are quite straightforward (and uncontroversial), and so should be easily enough coded up into separate policies.
But I can’t find any Camel policies for P::C. Do these not exist? Or are they hidden on DarkPAN? Surely someone somewhere must have begun work on this particular project of turning the relevant parts of Chapter 21 in perlcritic policies.
Or just maybe, since the book has only been out a couple of years in its current incarnation, this hasn’t been started yet. Would anyone out there be interested in such a set of policies being available?
I recognize that some of those “Style” matters fall more within the realm of perltidy than of perlcritic. That’s ok: I already have a perltidy config to help establish a standardized look for our new code base. It’s perlcritic policies that are giving me trouble right now, in that there just aren’t enough of them, and not the right kinds.
That does remind me of something else. Chapter 21 doesn’t include any of the advice from my famous Stack Overflow Unicode advice list. There really needs to be a P::C policy set for all that stuff, too.
I guess what I would like is for it to do the project one first, the ~user one second, and the per-directory one third, with later values overriding earlier ones. But it looks to me like it can only read at most one config file, not a chain of them with priority. Am I misunderstanding or missing something?
I would really like to see a set of Camel policies, plus various others. I also recognize that coding up all those policies is a lot of work, stuff I myself don’t have time for. That’s why I am hoping that someone else has already done so, or at least begun that work.
If not, then let’s please get that project going. Is this something that volunteers alone would be able to tackle? Or should we try to secure a funding grant to help pay for the development work?
I never, ever thought I would want anything like this, but if you were stuck with a few million lines of Perl Worst Practices code, I think you too might start thinking along these similar lines.
Thanks for all your ideas and help, suggestions and criticisms alike.
--tom
|
|---|