You would not use CGI.pm for maintainability reasons, but you would because its less work. Sounds like a good example to me...
Using the example of a system of many non-trivial CGI's, implementing something such as CGI.pm for reuse across all of them is going to be more maintainable and less work than rolling your own unique, simplest-method parser for each.
Your mention of 3rd party issues certainly makes the reuse issue more interesting, but copying/renaming CGI.pm into your repo and taking control is still more maintainable and less work than rolling your own a hundred times.
Where I come from anything of interesting scale is done in teams, and teams of teams. So everything is some level of "3rd-party". That's not a justification for each of us to duplicate each others work. Learning someone else's code is work. Past the xth reuse however, and the nth bugfix, the learning work is less than the rolling-your-own-again work.
Taken by itself, a single method, or single CGI might implement the simplest-possible option parser, and that's good. In fact you might have a hundred doing the same simplest thing, and that might also be good. Put them into the same system, and add the requirement that they should all exhibit similar usability behaviors. Then add a new style of behavior they must all adhere to such as your '-' example, and that's where simplest parsing method for each individual CGI becomes the nightmare to maintain system.
--Dave
In reply to Re^10: Legacy Code: "Dominoes = Bad"
by armstd
in thread Legacy Code: "Dominoes = Bad"
by locked_user sundialsvc4
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |