Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Starting a New Script

by LloydRice (Beadle)
on Sep 16, 2016 at 13:48 UTC ( [id://1171931] : perlmeditation . print w/replies, xml ) Need Help??

How do you start a new script? Do you just open a blank editor page and start typing?

I have written a Perl Code Builder that may be of some interest to somebody. To run it, you specify any number of capabilities this script should include, out of a catalog of a couple of dozen areas. Available capabilities range from a few simple trig functions and file read/write loops to a fairly elaborate PostScript code writer. You then open this "outline" script and finish rounding out the half-written pieces of code to do the current job. Since writing this, I have never started a new script from a blank slate.

Would this be of interest to anybody? If so, I will make it freely available.

Do similar things already exist? If so, I have missed seeing them.

Lloyd Rice

Replies are listed 'Best First'.
Re: Starting a New Script
by afoken (Chancellor) on Sep 16, 2016 at 18:48 UTC
    How do you start a new script? Do you just open a blank editor page and start typing?

    Yes, exactly that. I usually start with this:

    #!/usr/bin/perl use v5.12; use warnings;

    (In the old days, I used strict instead of v5.12, but now all machines that I use have at least perl 5.12 installed. Modules start with package Some::Package::Name instead of the shebang line.)

    From there on, everything depends very much on what kind of script / module I write and for what purpose I write it. Automating those three lines of code is a waste of time, simply because even those three lines may vary.

    I'm no big fan of generating tons of boilerplate code. If a system - especially in an OOP environment - needs hundreds lines of code just for a hello world program to work, something has gone horribly wrong in the early stages of the system.

    Loading your top 1000 modules in every script just because you could need one of them during the lifetime of one of your scripts looks as insane as the boilerplate aproach to me.

    Furthermore, every coder (except for the snake lovers) has his/her own preferences of how code should be structured, ordered and indented. The same is true for projects and companies, and of course, all preferences are different. So any code generator you could write either generates code using "the wrong style" or has a phantastillion of options allowing to configure any option, including the most insane ones. Naturally, you need to support at least a hundred different configuration mechanisms to fit all needs.

    During my professional carreer, I saw and used very different methods for creating new source code. "Do as I say (don't do as I do)", "Do what ever you want to solve the problem", "Use the only style that works", "Copy the templates and fill in your code, following the coding guidelines written on those two pages", "Copy some old code and modify it until it works", and of course "Follow this simple 350 page instruction manual to create a skeleton for a hello world program".


    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
      Yes, exactly that. I usually start with this: #!/usr/bin/perl
      use v5.12; use warnings;

      As do I, but for a few years now, I've left out the shebang line and use a call to perl instead. Whether I'm using an IDE (intelliJ IDEA with Vim plugin) or just Vim, I have a macro in my .vimrc that inserts it for me:

      iab _perl use warnings;<CR>use strict;<CR>

      Any time I'm writing a Perl file, I just go into Insert Mode, and type _perl, and it injects:

      use warnings; use strict;

      ...of course, I have a couple of others, but that's the one I use most often.

      As far as usefulness of the OPs project, I'd have to see it, but I doubt I'd be inclined to use it to be honest, for reasons yourself (afoken) and Your Mother have stated.

      ...and LOL at "the snake lovers"... I code in Python because I'm FORCED to, damnit! ;)

      ... (except for the snake lovers) ...

      ...and Java's Witnesses, whose preferences are often eclipsed by their IDE...

      perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
      ++ for "phantastillion". Made my morning.
Re: Starting a New Script
by Your Mother (Archbishop) on Sep 16, 2016 at 16:55 UTC

    I don't think I've heard of a similar tool but you have to take that with a grain of salt because, like a lot of devs, I don't use an IDE beyond the oldschool: vim|emacs. So I probably wouldn't know even if there were similar tools.

    I try to improve my coding practices every time I write something new so I tend to grab the last most similar script as a stub and start from there. Evolutionary editing.

    You don't need to ask anyone if your idea is useful. Just put the code on github or maybe even the CPAN and announce it. If it's useful, it'll find users.

Re: Starting a New Script
by shmem (Chancellor) on Sep 16, 2016 at 21:55 UTC
    Would this be of interest to anybody? If so, I will make it freely available.

    Of course yes, people might learn, the tool might spawn discussions which probably will generate further enlightenment. I guess the appropriate place to publish such a thing would be Cool Uses for Perl.

    How do I start a new script? Well, depends. If it is a straight forward task, I start with a blank page and type along. If the thing at hand requires new modules I'm not familiar with, I usually fire up my own enhanced version of perlsh included in Term::ReadLine::Gnu which writes a history file, fool around with that upon the modules in question until the bits are in place, and then I'll copy the good parts from the history into my new script editors buffer. No, not cut&paste. Two terminals aligned side by side, the left one holding the new script in vi, the right one paging the perlsh history with line numbers (less -N on Linux/Cygwin). Copying from right to left is done with

    :r ! l 42-64,96,14 .perlsh_history

    and $HOME/bin/l reads as follows:

    #!/usr/bin/perl -n BEGIN { $spec=shift; @l=split/,/,$spec; for(@l){ ($s,$e)=split/-/; $e||=$s; $_=[$s,$e]; } } CHECK { unless(@ARGV) { push @ARGV, <DATA>; chomp @ARGV; } die "usage: $0 linespec file\n" unless @ARGV; $file = $ARGV[0]; } # === loop ==== for $l(@l){ print if $.>=$l->[0] and $.<=$l->[1] } # === end === # END { if ($file) { open $fh,'<', $0; @lines = <$fh>; close $fh; open $fh,'>',$0; for(@lines){ print $fh $_; last if /^__DATA__$/; } print $fh $file,"\n"; } } __DATA__

    which code isn't posted to Cool Uses for Perl yet...

    perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
      "which code isn't posted to Cool Uses for Perl yet... "

      Perhaps it should be ;)

      ++ OP, for bringing up a conversation about tips and tricks that isn't necessarily editor specific. Although there are use-cases for editors, I like that this is general.

      I think anyone should post their Perl quick-tips here for instantiation of a new file/project. Most of us likely have many, that are hidden away somewhere.

Re: Starting a New Script
by ww (Archbishop) on Sep 16, 2016 at 14:52 UTC

    Details of the "catalog of a couple dozen areas" would be helpful in answering your question about interest.

      I find your potential offering interesting simply because it has value to you. (Otherwise you would not have made the effort I presume) I generally use Sublime Text 3 to write my code (Perl or otherwise) and have my own reasons for that particular editor none of which are all that compelling to anyone else I would guess.

      I have used Komodo in the past, and still do in a rare instance. But mostly I find that an IDE gets in the way. Like others mentioned here, there are a few lines that go at the beginning of the script.

      #!/usr/bin/perl use Modern::Perl qw(2014);
      beyond that, I use previously written code that is in use because I know it works for me.

      And I agree with others that Cool Uses for Perl would be a good place to refer to what you have done. If the code is substantial, then Github would be a great place to put it for others to examine and/or use. Makes for a good spot to let others comment and contribute, and your link in CUFP does not have to be updated every time you make a change.

      ...the majority is always wrong, and always the last to know about it...

      A solution is nothing more than a clearly stated problem...

Re: Starting a New Script
by neilwatson (Priest) on Sep 16, 2016 at 20:39 UTC
Re: Starting a New Script
by LloydRice (Beadle) on Sep 17, 2016 at 02:56 UTC

    Many thanks for the replies to my post. The first reply asked for some notes on what bits and pieces could be set up to start new code. I have included the command-line usage message printout. (USPTO is a contract I am working on.) And yes, it is strictly command-line, not a workspace as many assumed.

    I have heard of github, but have not looked into it. I will do that.

    MST 19:49:59.87 C:\temp:newpl Create a skeleton Perl script in the current directory. Usage: newpl [basename] ( optional function list ) ... If one or more function names are specified, the named function(s) will be copied, first by section then lowest priority first, from the master function scripts. Available functions are defined in \c\perl\function. Currently available master functions (p#=priority) include: p0: getargs test argument count and show usage message getopts parse command line arguments for -xx strings p1: envvar Expand an evironment variable in the form {VAR} uspto Extract 'uspto'-related user variable definitions uspto2 A new hash-based implementation of uspto uservars Create user variable hash %uservars log10 Return the base 10 logarithm of a number curdir Get the current working directory name p2: pi use the arctan function for useful multiples of pi time Various routines for dealing with date/time usetime More time demos and applications defext Add a default extension to a given path/file name defext2 Like defext, but includes the forceext function fread Open a file for reading fwrite Open a file for writing readdir Open a directory for reading readsrf Read an SRF file, saving field values in a 2D array psstuff The full Postscript pkg (for direct PS printing) ps_usefmt Include the Postscript pkg (using (pagefmt) run) pause Pause and continue or exit p3: strpack Convert between char strings and index lists cmdline A simple console-interactive command loop

      Without seeing more of the code it is hard to get a good answer. Based solely on the usage information, it sounds like you should consider moving the functions into modules or using existing modules from CPAN (because most if not all of that functionality is already available). Then you could either ditch the script or modify it so that it creates a script that uses the appropriate modules and only imports the functions requested.

Re: Starting a New Script
by ambrus (Abbot) on Sep 20, 2016 at 08:27 UTC

    How do I start a new perl script? Usually it happens when a one-liner grows too big (more than about five lines), or I find that I will want to run it again later. In that case, I copy the one-liner into a text file, and add some line breaks and other cleanups to make it more readable as it grows bigger.

    Less often, I already know that I want to make a long re-usable script, in which case I just type something like

    #!perl use warnings; use 5.014; print "hello, world,"; __END__
    into a script, run it, then grow it from there.

    In either case, I try to add code for the things it should do, one by one in order. I try to ensure that at each stage when I add a new part, I can run the script and get some sort of feedback diagnostic so I can see that it works. Eventually, I get a complete script I can run or modify.

Re: Starting a New Script
by wazoox (Prior) on Sep 23, 2016 at 13:30 UTC
    I have set up a keyboard shortcut (Ctrl+Shift+p) that inserts
    #!/usr/bin/perl use v5.14; use warnings;

    I have a couple of other perl shortcuts :)