Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Perl tools for making code better

by Leitz (Scribe)
on Jun 29, 2021 at 14:02 UTC ( [id://11134441]=perlmeditation: print w/replies, xml ) Need Help??

I have bodies of code to maintain and improve. Using tests is a given, and TDD is a wonderful thing. I am still learning Perl culture, and would appreciate guidance on tools and processes.

My parameters are hopefully simple. I prefer clear and verbose code so I can understand it the next time I read it. When producing tools I prefer to stay as close to Core/StdLib Perl as possible. When working *with* tools, more options are open. For example, using a Perl::Critic plug-in while developing code is fine, shipping those add-ons is something I would avoid.

My current plan is a cycle of:

  1. Write Tests
  2. Kwalitee
  3. Perl::Tidy
  4. Perl::Critic

Repeating as necessary, or until I have to ship the code. Are there other tools to add to the mix? Better processes?

Chronicler: The Domici War (domiciwar.net)

General Ne'er-do-well (github.com/LeamHall)

Replies are listed 'Best First'.
Re: Perl tools for making code better
by Tux (Canon) on Jun 29, 2021 at 14:17 UTC

    Have a look at Release::Checklist. The doc is an exposition of all (perl) tools to improve your perl module (and code).

    All you stated yourself is already part of that doc :)


    Enjoy, Have FUN! H.Merijn

      Tux, excellent work; thanks! I'll be studying that.

      Chronicler: The Domici War (domiciwar.net)

      General Ne'er-do-well (github.com/LeamHall)

Re: Perl tools for making code better
by kcott (Archbishop) on Jun 29, 2021 at 19:34 UTC

    G'day Leitz,

    That's a great list from ++Tux. I also use the core module, ExtUtils::Manifest; typically like this:

    #!perl use strict; use warnings; use Test::More; BEGIN { if (! $ENV{RELEASE_TESTING}) { plan skip_all => 'Author test: $ENV{RELEASE_TESTING} false.'; } } use ExtUtils::Manifest qw{manicheck filecheck}; plan tests => 2; is_deeply([manicheck()], [], 'Check files in "MANIFEST" exist.'); is_deeply([filecheck()], [], 'Check for files not in "MANIFEST" or "MA +NIFEST.SKIP".');

    I typically create modules using Module::Starter via module-starter with Module::Starter::PBP as a plugin.

    "For example, using a Perl::Critic plug-in while developing code is fine, shipping those add-ons is something I would avoid."

    If you're using, for example, Test::Perl::Critic for development but you're not shipping it, you will have to remove the test from your t/ directory and modify your MANIFEST file prior to running "make dist". You will need to do this for possibly quite a few similar tests. This would be tedious as well as being error-prone (easy to get the two versions out of sync). Consider using "... skip_all => 'Author test ..." as I showed in the code above.

    There was some recent discussion about naming conventions for test files. You can see how I normally number these. For "Author tests", I have recently been adding 99- to the start of those (which I find makes it clear what they are). A listing of my t/ directory would typically include files like:

    99-00_pod.t 99-01_pod_coverage.t 99-02_manifest.t

    Do note that is what I choose to do. Others have their own conventions. Do not feel in any way compelled to follow what I do.

    — Ken

Re: Perl tools for making code better
by eyepopslikeamosquito (Archbishop) on Jun 30, 2021 at 00:09 UTC

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://11134441]
Approved by GrandFather
Front-paged by kcott
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others musing on the Monastery: (4)
As of 2024-04-25 16:51 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found