>Given the ghastliness of maintaining Perl code I've had to maintain perl code at work, so you have my sympathies.
But in Perl's defense, it's not a necessary characteristic of Perl to be hard to maintain. It's just the inherent flexibility of the language that makes it easier to write "Write Only Code". Given that you are refactoring at all shows that, while Perl has the flexibility to be written in an overly complex way, it can also be written to be maintainable, even in large projects. As for the lack of comments in the code, I've read some interesting opinions about the practice of commenting. That bad comments are worse than no comments at all, and that comments themselves tend to be the first victim of code rot. I've seen some comments in production code, that if it weren't for the NDA, would have been sent to www.thedailywtf.com. Using self-documenting code practices, sticking to the standards set out in "Perl Best Practices", and the constant use of Perlcritic has reduced the amount of comments I've needed to put into code, as well as the need to maintain the comments. Which, in my opinion, can be harder than maintaining the code. There are no compile or run time error or warnings for an out-of-date comment. One extreme view was that comments in the code should be avoided as the need to comment was a sign that it was time to refactor of the code instead. That said, people who don't put descriptive comments with their submits need shot. :) I've got a bit of free time on my hands, perhaps you want some help refactoring? H. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org