Re: Strategies for maintenance of horrible code? (Legacy Code References)

[eyepopslikeamosquito]

Yes, it would have been cheaper and faster to throw this code away and start over

Maybe. For another point of view, see Joel Spolsky on not rewriting from scratch.

I agree with adrianh. If a component is not broken, don't rewrite it. Rewrite a component when you find a number of bugs in it. But first write a regression test suite for the component. I've seen many folks over the years throw out old code, rewrite it ... and introduce a heap of new bugs in the process. If you come into a new company and introduce a swag of new bugs in previously working code, you will start to smell very badly.

See also:

• Nobody Expects the Agile Imposition (Part VI): Architecture - lengthy and at times heated discussion of refactoring vs rewriting of large code bases (perl5 internals compared to Jenga :-)

• Perl Medic: Transforming Legacy Code by Peter J. Scott
• Working Effectively with Legacy Code by Michael Feathers
• Object-oriented Reengineering Patterns book now available as a free download

• The Boy Scout Rule (apply the Boy Scout rule of "leave the campground cleaner than when you found it" to your code)
• Re: Moving from scripting to programming (tips for writing industrial strength code that lasts a long time)
• Unix shell versus Perl (explains why Perl is a better choice for large code bases than Unix shell)
• Re: I need perl coding standards (Coding Standards References) (list of general references on code standards and style advice)

• Swallowing an elephant in 10 easy steps by ELISHEVA (Describes how she tackles big problems to keep moving forward rather than going around in circles)
• Dealing with sloppy code
• Becoming familiar with a too-big codebase?
• Analyzing large Perl code base.

• Second-system effect (wikipedia)

Legacy Code References Added Later

• Backdating strict
• sed/awk/grep to Perl
• Working with old code
• Splitting program into modules
• Searching for duplication in legacy code
• Perl archeology: Need help in refactoring of old Perl code that does not use strict
• Reading Someone's Program
• Code Structure Changes
• Perl Elitist Code vs Functional Code
• Meaning of "Clean" Perl code
• How to retain perl in-house code
• Cleaning up unused subroutines
• documentation best practices for internal modules
• Rule of Three (wikipedia)

• Re: Using the perl debugger to look at a renaming files function (on Debuggers References) (on debuggers)
• Re: Re: Re: Are debuggers good? by merlyn (aggressive approach to rewriting unmaintainable code)
• "Your code sucks" by afoken (tales from maintaining legacy real-time code where bugs can kill people)

• Strategies for maintenance of horrible code? by converter (on rewriting horrible perl code left behind by his predecessor)
• Legacy Code by GotToBTru (some examples of poorly written legacy code)
• There's Only One Way To Do It by jdporter (compares Perl with Java)

• The future of Perl? by BrowserUk (2014)
• Re^4: The future of Perl? (Legacy Code Quotes)

Bad Code References Added Later

• Suggestions for working with poor code by Ovid (2001)
• The joys of bad code by BUU (2004)
• Need Bad Code by SleepyJay (2007)
• Re^3: Where to place POD by hv (2024)

• The Daily WTF
• Competition: deceptive code by sfink (2008)
• Things are not what they seem like. by Abigail (2000)
• can someone help me? by xiper (2004)

Testing References Added Later

• Re: Winning people over to better development practises (TDD)
• Effective Automated Testing
• What is the best way to add tests to existing code?

• Looking for help for unit tests and code coverage on an existing perl script
• Needing help on testing
• How do you test end-user scripts?
• A brief question about testing/best practices
• How to write testable command line script?

Updated: Added many extra references long after the original response was made.

[GrandFather]

Actually, just writing the tests is often a damn fine way of finding bugs. No exactly what OP is after at the moment, but something that is at the forefront of my mind because I'm in the middle of writing a set of tests (in Perl :) for some XML processing C++ code and turning up a pile of bugs as I go.

However it does suggest another test avenue: write test harnesses for modules so that you can exercise them in isolation and better understand how they work. If the test harness ends up part of a regression test system so much the better.

[tinita]

Maybe. For another point of view, see Joel Spolsky on not rewriting from scratch.

uh oh. why does this remind me of perl 6? =)