So I've got a ton of code right now (a well built system) that does not use strict, has tons of subroutines and is very well organized that uses my $var, at every occassion, and, uses return(); when no return $var is required. It's clean, efficient and it works.

Since this may be a daunting task, can you break your large system into smaller components that can be tested in isolation? (sounds problematic due to your heavy use of globals). If you can do that, at least you can then convert the system to be strict-safe one component at a time.

It uses a lot of requires IE 'process.pl', 'whatever.pl'. (files required only when necessary)

Update: See also: So I'm in a bit of a quandary

If you can do that, at least you convert the system to be strict-safe one component at a time.


yes, this... I think I've got it.



How much of this "well built system" has regression tests around it?


Never been that route, but probably About 20 million dollar wise in transactions to date; hundreds of thousands of transactions.

What's a regression test? I don't do corporate perl, I just do perl.

write a comprehensive regression test suite
Ok I was looking for some real world stuff to deal with this but I think I got what I needed based on your 'one component at a time' comment. Thanks much for your input. :-)

What's a regression test?

Currently, how do you test your software? Is it ad-hoc manual testing? Or do you have formal manual test plans you run through? Or do you use automated testing?

As you change your code to use strict, there is a risk that you may accidentally break a working system. If you have an automated regression test suite in place, you can:

1. Run the automated test suite. It passes. Good.
2. Make your code changes to make the code strict-safe.
3. Re-run the automated test suite. If it now fails, you know that your code change broke the system.

Of course, if your automated regression test suite is mickey-mouse, passing all the tests doesn't mean much. But if you have a comprehensive test suite in place it gives you much greater confidence that you haven't accidentally broken the system while cleaning up the code.

BTW, note that Perl itself has a comprehensive automated regression test suite (run with "make test" when you build Perl). This test suite is an invaluable safety net to Perl developers as they change the (fragile) perl C source code.

What's a regression test?

See regression test.

Welcome perlidiot123,

Try using <ul><i> and </i></ul> around comments from a previous post like this:


---

If you can do that, at least you convert the system to be strict-safe one component at a time.

yes, this... I think I've got it. ( your comment )

---

IMHO, It helps the readers understand your responses.

About your real question, I think its a slow process of fixing existing scripts one at a time.

About 8 years ago I had the same situation. I starting using strictures, but only if I needed to update an existing process. Many of the old are running in production without re-write, but if I add something new or need to update a process, you can be sure I use strictures plus better Perl techniques.

Every time you look at older code, you can see a better way. Good Luck!

Regards...Ed

"Well done is better than well said." - Benjamin Franklin

Also very interesting is the Modulino idea explained in mastering perl by brian d foy.

Sure, for about half a second :) "modulinos" are fudgy :) modulino and perldoc, Re: modulino and $VERSION (all code in module , script as module )

I feel like the Gods at perlmonks are looking down on me telling me I suck

No one thinks you suck and this is not a pro v amateur question. It’s a matter of remote help and effort involved. If you have a 10,000 line script with homemade modules all without strict or warnings and you have an error and come here to ask: Why is it broken? No one is likely to help because it could be 100,000 things and except in very lucky or obvious circumstances, it will be painful to figure out, if not impossible, without seeing all the code.

use strict; protects you and makes getting free, professional help eas(y|ier) for the professional which also makes it more likely to happen. I think you can see the difference between saying: Please help me, it will probably be easy for you and Please help me, it might be impossible or take several hours of your time. That’s where the, sometimes hostile, push-back against eschewing strict originates.

I'd like to convert this big thing to a complete use strict

the Gods at perlmonks are looking down on me telling me I suck

And I hope he will write a similar book for Perl 6 some day

From Interview with Damian Conway:

And I can certainly see myself writing a book on Perl 6 best practices. But I can't see myself writing the best practices book until I have 5 or 10 years experience of what people do wrong in the language. That's where the best practices come from. Seeing the mistakes that people make and the consequences of those mistakes...and we don't know what they are yet. To write Perl 6 best practices needs a lot of experience in the community, and a lot of feedback, and me teaching a lot of people and finding out what they don't do right.

Hello perlidiot123, and welcome to the Monastery!

I'd like to convert this big thing to a complete use strict as well as convert my design philosophy to using strict 24/7.

Saying use strict actually invokes all of the various strict pragmata; currently there are three: refs, subs, and vars. So if you convert your code to use strict, you should approach this as three separate tasks:

1. use strict 'subs'. This produces a compile-time error if the compiler finds a “bareword,” meaning an unquoted sequence of characters which the compiler cannot unambiguously identify as a variable name, function name, numeric constant, filehandle, etc. AFAICT, this can occur in only two cases: (1) a string which is unquoted; and (2) a subroutine call on a sub which is undeclared and is neither preceeded by & nor followed by (). In both these cases, the compile-time error will alert you to the problem, and the fix (quote the string or call the sub explicitly) is safe from adverse consequences or side effects.

2. use strict 'vars'. This produces a compile-time error if the compiler finds a variable which has not been declared with my, our, state, or use vars, and which is not fully qualified with a package name. It is this aspect of strict which most Perl programmers think of when they think of use strict.

   I guess I'm just tired of hiding in the shadows of "Use everything, ie declare all $vars as OUR"

   Actually, if you do declare your global variables with our, you will satisfy the use strict 'vars' pragma and you will still gain some advantage over using undeclared package globals. A useful reference is Ovid’s 'our' is not 'my'. Of course, your long-term goal is to convert all the our variables (package globals) that are not shared between packages into my variables that cannot be (accidentally) so-shared. In doing this you will need to be careful to identify those variables which are meant to be shared. A text editor can help you here to some extent — if you have a variable $Foo::bar and the name $bar occurs only within the Foo package, you can be confident that it isn’t shared between packages — but where the same variable name is used across different packages, only a careful analysis of the code will tell you whether or not the variable is acutally shared.

3. use strict 'refs'. This prevents the use of symbolic references (see How-can-I-use-a-variable-as-a-variable-name of perlfaq7). If your existing code does make use of symbolic references, the good news is that they can usually be fairly easily replaced with hard references. The bad news is that the use strict 'refs' pragma generates a run-time error (and not a compile-time error) when the interpreter encounters a symbolic reference. This means that if you get no errors under use strict, you can’t be sure that there are no symbolic references lurking undetected. If a symbolic reference appears in a seldom-visited execution path, your new code may appear to work for a while and then die unexpectedly. Once again, you need to make a careful analysis of the code to ensure that no symbolic references are being used.

Hope that helps,

Hi,

Very, very carefully.

Do you know the phrase -

if not look it up.

You are talking about working production code, handling many transactions, covering loads of money.

Start all you new progs with strictures, but leave this stuff alone until you are forced to do something to it.

J.C.