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

[Anonymous Monk]

1) ... strict pragma ...My time to make the conversion is limited and using some off the shelf tools that speed up the process would be a great help.

Hurry up and leave it alone :)

 use strict; itself confers no benefits; The benefits come from avoidance of the bad practices forbidden by  strict :)

That pretty much means convert one at a time by hand after you have learned the understanding of importance of knowing :) Speed kills

2. If possible ... I do not understand ...

That is a hint you shouldn't be refactoring anything programmatically.

There are a million nodes on perlmonks, and a readers digest version might be Modern Perl a loose description of how experienced and effective Perl 5 programmers work....You can learn this too.

Hurry up and bone up

3. Generally this task looks like a case of refactoring. I wonder, if any Perl IDE has some of required capabilities, or are there tools that can helpful.

I hope you have foot insurance :) happy hunting :) perlcritic, PPI/PPIx::XPath , PPIx::EditorTools,
App::EditorTools - Command line tool for Perl code refactoring
Code::CutNPaste - Find Duplicate Perl Code

 

So enjoy, test first, step0++

[likbez]

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.

[chromatic]

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.

I don't get anything out of it if you read it or don't, but it's a shame that you might give other people the impression that the book tries to do something it was never intended to do. For example, you won't see anything in the book about using:

• Smartmatch (except "don't use this")
• Postfix-dereferencing (because it wasn't explicitly marked as stable for the version supported in 4e)
• Subroutine signatures (again stability)

The book has always been freely available online, in all of its versions. I'm disappointed that you'd write this without having at least skimmed the book for yourself to see if it's true. (It's not.)

[eyepopslikeamosquito]

unhealthy fascination with OO (inspired by the desire to complete with Python) which I consider counterproductive

Python? Really? Do you mean Ruby? Quoting Matz from An Interview with the Creator of Ruby: "Then I came across Python. It was an interpretive, object-oriented language. But I didn't feel like it was a "scripting" language. In addition, it was a hybrid language of procedural programming and object-oriented programming. I wanted a scripting language that was more powerful than Perl, and more object-oriented than Python."

When I see bless statement in simple scripts I suspect fraud

That's an extreme position to take. Though an obsession with OO is unhealthy, your apparent anti-OO obsession is just as unhealthy IMHO. Don't want to use Moose? Fine. But don't blindly reject sound principles of design - which include using OO when appropriate. As for whether and when to use OO, there is no substitute for judgement and taste. A simple rule of thumb is to ask "do I need more than one?": if the answer is yes, an object is indicated; if the answer is no, then a module.

High-level Design Checklist (derived from On Coding Standards and Code Reviews)

• Coupling and Cohesion. Systems should be designed as a set of cohesive modules as loosely coupled as is reasonably feasible.
• Testability. Systems should be designed so that components can be easily tested in isolation.
• Data hiding. Minimize the exposure of implementation details. Minimize global data.
• Interfaces matter. Once an interface becomes widely used, changing it becomes practically impossible (just about anything else can be fixed in a later release).
• Design the module's interface first.
• Design interfaces that are: consistent; easy to use correctly; hard to use incorrectly; easy to read, maintain and extend; clearly documented; appropriate to your audience. Be sufficient, not complete; it is easier to add a new feature than to remove a mis-feature.
• Use descriptive, explanatory, consistent and regular names.
• Correctness, simplicity and clarity come first. Avoid unnecessary cleverness. If you must rely on cleverness, encapsulate and comment it.
• DRY (Don't repeat yourself).
• Establish a rational error handling policy and follow it strictly.

Some Related Perl Monks Nodes

• Strategies for maintenance of horrible code?
• Moving from scripting to programming
• Code Structure Changes
• What is the best way to add tests to existing code?
• Reading Someone's Program
• Object-oriented Reengineering Patterns book now available as a free download
• On Coding Standards and Code Reviews
• Nobody Expects the Agile Imposition (Part VI): Architecture
• The Boy Scout Rule

[likbez]

Python? Really? Do you mean Ruby?

IMHO in large enterprise environment Ruby is almost not visible. At the same time Python is gaining ground as universities both in the USA and Europe now teach Python in intoductory classes and people come "knowing some Python". That's alone is a huge factor. Python is also now installed on all Linux distributions by default (like Perl) and there are some system programs written in Python (yum, Anaconda, etc) which implicitly suggest that Python has Red Hat mark of adoption too.

To say nothing about the list of IDE available. Perl does not even ship with the "Standard IDE" although Padre, which is somewhat competitive with Komodo is available for free, but the latest binary distribution suitable for beginners is from 2012. This IMHO is highly detrimental to the language adoption. My feeling is that for Perl to remain competitive IDE should be maintained and shipped along with Perl interpreter. May be at the expense of some esoteric modules included.

Also compare number of books per year devoted to Python and available via Amazon for 2017 with the number of books devoted to Perl for the same period(quality issues aside). All this creates a real pressure to use Python everywhere, the pressure that I as a person who uses Perl (and will continue to use it, as I prefer Perl to Python) feel.

In other words "It's like deja-vu, all over again": looks to me like "Java story" on new level (and with a better language then Java).

Even in such "Perlish" domain as bioinformatics/genome decoding, Python gradually gains ground at the expense of Perl. The same is true in some "numeric computations" domains (via Numpy). There might be other factors at play as well. That's sad, because IMHO Perl is a great scripting language which can be used on many different levels, starting from AWK/SED replacement tool.

The list of references to related Perl Monk posts is really helpful. Thanks a lot !

Especially the first one Strategies for maintenance of horrible code? by converter (Jul 12, 2006). It contains several additional useful references posted by eyepopslikeamosquito

I would also add Analyzing large Perl code base. by Dmitry (Apr 14, 2005). Among others it contains the following post:

Re: Analyzing large Perl code base. 
by dave0 on Apr 15, 2005 at 15:32 UTC  
====================================

Having recently done this on a fairly large codebase that grew organically (no design, no refactoring) over the course of four years, I feel your pain.

Writing a testsuite, on any level, is nearly essential for this. If you're rewriting an existing module, you'll need to ensure it's compatible with the old one, and the only sane way to do that is to test. If the old code is monolithic, it might be difficult to test individual units, but don't let that stop you from testing at a higher level.

B::Xref helped me make sense of the interactions in the old codebase. I didn't bother with any visualization tools or graph-creation, though. I just took the output of perl -MO=Xref filename for each file, removed some of the cruft with a text editor, ran it through mpage -4 to print, and spent a day with coffee and pencil, figuring out how things worked. <p. Pretty much the same tactic was used on the actual code. Print it out, annotate it away from the computer, and then sit down with the notes to implement the refactoring. If your codebase is huge (mine was about 4-5k lines in several .pl and .pm files, and was still manageable) you might not want to do this, though.

In any case, attempts to create a relevant to this topic list of Permonks threads is a more constructive approach then yet another semi-religious discussion about proper use of OO in Perl. Your mileage may vary.

[Anonymous Monk]

Hi

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.

You can be strict/warnings compliant and not benefit

Being in a hurry to automate strict/warnings compliance hints that you just might be missing the point of strict/warnings

The slideshow I linked is very good, its called Program Repair Shop , its about refactoring/strict/warnings

So this is an implicit attempt to push me into "overachiever mode".

No, Its an explicit invitation to answer question #2 yourself,

Chapter 9. Managing Real Programs, Modules, Organizing Code With Modules

I'm boning up right now

Its hard being an archeologist