[Novalug] Suggestions for web interface?

William Sutton william@trilug.org
Sun Dec 11 20:48:35 EST 2016


/me rushes to Perl's defense:

It's "Perl", not "PERL".  Not an acronym.

I was a full time Perl programmer for over 10 years.  I've seen a lot of 
people's ugly crappy Perl.  I've refactored most of it.  My last 
significant Perl codebase was 15k-18k lines of Perl, SQL, PL/SQL, T-SQL, 
and XML (the last being mostly config), all OO.

First thing that helps is perltidy -b -gnu (or whatever other formatting 
style you like).  The goal is to have a code tidier clean up the obvious 
ugliness.

Second thing that helps is syntax higlighting.  It usually makes obvious 
quoting issues apparent, and can help break the monotony of monochromatic 
code :-)

Third and fourth essential things, in tandem:  use strict and use 
warnings.  With most bad code, this immediately breaks everything.  That's 
good.  Start explicitly declaring variables and fix anything else that 
fails to pass a perl -c check.  This also includes getting rid of chains 
of implicit $_ statements.  Use of implicit $_ relies on nothing else 
changing $_, and that's a dangerous assumption (especially in anything 
threaded or forked).

For that matter, the general Perl help advice on threading is "Don't."

Once you have finished that stage, and the code still does what it's 
supposed to, it is time to seriously refactor the code.

Figure out appropriate logical divisions, and reimplement them properly. 
Where you can, use Perl modules or native Perl constructs instead of 
shelling out.  Where you *must* shell out, verify the output before using 
it.  Use the taint option for better security.

If you can, modularize your Perl with OO.  Perl isn't inherently OO the 
way Java is, but doing OO Perl can force you to break things out more 
cleanly than the typical "big ball of mud".  It also allows for better 
code reusability.  Frameworks like Moose help.

Find a clean programming style and stick with it.  People will argue about 
formatting and style until the end of time, but be consistent.

And last, but certainly not least, DOCUMENT THE CODE.  POD is particularly 
helpful since you can run perldoc on your code and it will render the 
documentation simlarly to man pages.  This is especially true if you 
follow the JavaDoc style in Perl POD.

William Sutton

On Sun, 11 Dec 2016, Ed James via Novalug wrote:

> Too many years spent debugging and fixing OPPPs (Other People's
> PERL Programs.  I kinda enjoyed writing PERL programs from scratch,
> but really hated reading messy code, especially since much of it was
> under "on call duty" during emergencies on live systems.
>
> I do remember with fondness the O'Reilly "PERL Cookbook" (the Ram book?),
> among others.
>
> EJ
>
> On Sun, Dec 11, 2016 at 7:14 PM, jerry w <jerrywone@gmail.com> wrote:
>
>> What's wrong with Perl?
>>
>>
> **********************************************************************
> The Novalug mailing list is hosted by firemountain.net.
>
> To unsubscribe or change delivery options:
> http://www.firemountain.net/mailman/listinfo/novalug
>


More information about the Novalug mailing list