[Novalug] Suggestions for web interface?

Ed James edward.james@gmail.com
Mon Dec 12 06:12:02 EST 2016


I really wish the Perl coders where I used to work had actually followed
all that advice, but make DOCUMENT THE CODE "first", not last.  The
environment rewarded devs who got code into production fastest/cheapest,
but the other group, who had to make live, emergency fixes certainly did
not reap that "benefit".  OTOH, it helped keep me employed at various
sites. Code documentation was sparse.  My style is to write "pseudo code"
(simple English statements of what was being done) first, then head-check
it out for logic, flow, efficiency, yada.  Then I'd comment it out and
insert real code (for whichever language I'm working with).  This does slow
down initial code writing, but "the sooner one starts coding, the longer it
takes" was a dear lesson to learn.

There was no "official style", since code was written over years by
different groups. But yes, that would certainly have been of value.  IMHO,
your list would have made my life "back then" a whole lot smoother, and
prolly still would for whomever is still there.

The comment about "use strict and use warnings" is well-taken.  I follow
"paranoid mode" in C++ compiling, looking for any/every warning, and coding
to avoid even innocuous-seeming warning.  This was something started back
in Java-coding days, vis-a-vis getting rid of deprecation warnings in
particular.

EJ

On Sun, Dec 11, 2016 at 8:48 PM, William Sutton <william@trilug.org> wrote:

> /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