Clear questions and runnable code
get the best and fastest answer
Paradigm Shift - Don't use strictby Ovid (Cardinal)
|on Nov 12, 2001 at 22:47 UTC||Need Help??|
Imagine the following: you're facing a serious programming problem and a coworker tells you not to reinvent the wheel. There's a module that will do just what you need. Rather than just blindly use this module, you decide to give it a code review. Here's what you find:
Most variables are global. In fact, much of the module's configuration is controlled by global variables.
Hand-rolled version of Exporter. The author was concerned about performance, so he rolled his own.
To make his code as desireable as possible, the author decided to give users the ability to use the code as both functions or object methods, thus, in your view, unnecessarily complicating the code. Maintenance is rather tricky (just try inheriting from it).
Plenty of symbolic references, such as the following:
The following line can be found in the contructor:
At least one function has the same name as a standard keyword, forcing the author to use CORE:: to call the original function. Other functions had to be renamed from their originals in prior versions due to collissions with Perl's built-ins.
Needless to say, after discovering all of this, you're absolutely horrified and tell your co-worker that under no circumstances will you use CGI.pm.
The above information is valid for $CGI::VERSION='2.752'. I went and downloaded CGI.pm VERSION 2.0 and most, if not all of these points were still valid.
Please note that I am not advocating that anyone abandon this module. I just wanted to take the time to point out that some good programmers can violate the rules and get away with this. In this case, many of the issues above stem from the fact that this is legacy code that has been constantly upgraded.
Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.