Re^4: Working with old code

in reply to Re^3: Working with old code
in thread Working with old code

Let me get this straight. It started with a small Perl 4 style script, written in Perl 5 by a hubristic C programmer? Did the basher rewrite it in bash? Or just add some bash to the existing Perl 4-style Perl 5 script? Did the Java fan boy rewrite the whole thing in Java, or just add some Java to the existing Perl 4-style Perl 5/bash hybrid? ... I agree that a "Perl4-style Perl 5-bash-Java hybrid" written by a C programmer is probably ripe for a complete rewrite. :)

my second project ever was a complete rewrite of the crap I wrote in my first project. After I discovered how it really should be done

Sure, this can work well ... like the Perl 5 rewrite of Perl 4 ... or not so well, like the Perl 6 rewrite of Perl 5. :) Beware the Second-system effect.

Comment on Re^4: Working with old code

Replies are listed 'Best First'.
Re^5: Working with old code by karlgoethebier (Abbot) on Jun 28, 2020 at 20:08 UTC
All pure Perl. But everybody speaks his second or third language with some less or more strong accent. Like me when I talk English like Armin Müller-Stahl in ŤNight On Earthť by Jim Jarmusch. The C guy declared all variables on top and used C-style loops. The Bash guy shelled out whenever possible and added an extremely long main part. The Java guy turned the whole thing into bloatware. Just to mention a few issues. Best regards, Karl ŤThe Crux of the Biscuit is the Apostropheť `perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'`Help	[reply] [d/l]
Re^6: Working with old code by eyepopslikeamosquito (Archbishop) on Jun 28, 2020 at 20:51 UTC
Successful software development is a long term activity. If you plan to be successful, you should therefore plan for your code base to be maintained by a succession of many different programmers over a period of many years. Not planning for that is planning to fail. -- from Why Create Coding Standards and Perform Code Reviews? Sounds like you might have benefited from code reviews and a company coding standard. BTW, I see that Perl monk JavaFan was very dubious of the benefit of a company coding standard in Why Create Coding Standards and Perform Code Reviews? Maybe he was the "Java fan boy" in your old company? :) Though we've had a company Perl coding standard for many years, consistently enforcing it was problematic. It still exists but is advisory only, rarely enforced. Peer code reviews are still mandatory.	[reply]

In Section Seekers of Perl Wisdom