http://www.perlmonks.org?node_id=1203409


in reply to Re: Perl archeology: Need help in refactoring of old Perl code that does not use strict (hurry up and wait)
in thread Perl archeology: Need help in refactoring of old Perl code that does not use strict

use strict; itself confers no benefits; The benefits come from avoidance of the bad practices forbidden by strict :)
That's very true. But if we are talking about the modernization of legacy code this advice sounds like "it is better to be rich and healthy, than poor and sick" ;-)

The code is valuable and will probably live another 20 years and so leaving it alone is not an optimal solution. And modernization always has resource constrains so it is important not to "overachieve". I chose a very modest goal -- implementing "strict" pragma because "use strict" and "use warnings" are two pragmas which do improve maintainability of Perl scripts. Other new staff mostly don't.

Not to open religious wars, but as for your recommendation to read "Modern Perl" I respectfully reject it because I suspect that chromatic is a "complexity junkie" in heart :-).

So this is an implicit attempt to push me into "overachiever mode". By "overachiever mode" I means conversion of the code using all those fancy idioms available in Perl 5.22 and above and advocated by chromatic, especially unhealthy fascination with OO (inspired by the desire to complete with Python) which I consider counterproductive. When I see bless statement in simple scripts I suspect fraud :-). Also during modernization of legacy code it is important to respect the original author way of thinking and coding.

BTW when they introduced escaping opening curvy brackets in regex in 5.22 (which was a blunder) I thought that now all bets are off and I am staying with teen versions of Perl forever ;-). Later I changed my mind and use 5.26 is some cases, but the problem remains: inability to reduce complexity of the language, only add to it, sometimes screwing previously healthy parts of the language in the process.