Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Developing code to be a module

by rpnoble419 (Pilgrim)
on May 01, 2013 at 04:13 UTC ( #1031493=perlquestion: print w/ replies, xml ) Need Help??
rpnoble419 has asked for the wisdom of the Perl Monks concerning the following question:

I was curious as to the way other monks develop code to be turned into a module. I usually take the code in question and turn it into a function, then I get all of the input, error trapping and output working as I want. Once working, I take that code and turn it into a module. It works for me. What works for you?

Comment on Developing code to be a module
Re: Developing code to be a module
by space_monk (Chaplain) on May 01, 2013 at 05:42 UTC

    I hope this doesn't sound too rude, but the way you've described reeks of having no forward planning or idea of where you want your code to get to. Code shouldn't have to be 'turned into' a module; it should have been planned to be a module or modules in the first place.

    Even for apparently trivial projects, you should spend some time thinking about how it breaks down into packages/objects before you start to code. You should look on CPAN, PerlMonks, StackOverflow etc to see if anything similar has been done before. With a little luck you may not have to write a line of code yourself. I think the mark of a good developer is not how many lines of code he/she produces, but how much of the problem he solves using existing solutions.

    Also you should have some method of verifying your code does the job it is supposed to. Look at Test Driven Design as a methodology, and Test::Simple and/or Test::More as potential packages to ensure you have Unit tests to verify your package does the job it is supposed to.

    Also have someone else look at the problem or code. A second pair of eyes often confirms that you are a Programming God, or points out a better way, from which you can learn. Both results are good. :-)

    If you spot any bugs in my solutions, it's because I've deliberately left them in as an exercise for the reader! :-)

      Lots of folks write programs that don't have functions, programs that don't start from a template

      #!/usr/bin/perl -- use strict; use warnings; Main( @ARGV ); exit( 0 ); ...

      This is typical for short programs and one-offs

      And you can't beat perl lanse :)

      $ echo hi there | perl -lanse " print qq{$greet\t$F[1]}" -- -greet=by +e bye there $ echo hi there > stuff $ perl -lanse " print qq{$greet\t$F[1]}" -- -greet=bye stuff bye there

      These types of programs can live and do good work quite for a long time before they need a second look, or functions/modules/tests...

      Code doesn't need to go places :)

        I don't have a problem with "Perl Golf" short solutions to problems and sometimes use them myself. I even have a go at some of them on here! :-)

        However its obvious the OP (Original Poster) is not talking about those basic sorts of problems.

        If you spot any bugs in my solutions, it's because I've deliberately left them in as an exercise for the reader! :-)
      Many of us toiling at the "adminface" will develop a "-e" solution to a specific problem, which subsequently becomes a script as it "got a little complex".

      When it becomes a script strictures are applied and the code get slightly neater.

      Then a couple of weeks/months/years later you end up automating a process around this script, at which point it needs to be "modularised".

      At that point we add tests so that future development doesn't lead to regressions etc... and our humble script has made it through the admin's software lifecycle, it bears a passing resemblance to a developers software lifecycle after this stage has been reached.

      Personally I wouldn't count the failure to anticipate a simple flip-flop filter with an END block becoming a full blown log file parsing tool for a production service as bad coding.

      print "Good ",qw(night morning afternoon evening)[(localtime)[2]/6]," fellow monks."

      Space_monk;

      Thank you for the time it took for your reply but you missed my point. I was trying to see how others perform their tasks. I'm not a perl newbie (started with perl 4) and have been a professional programmer for over 30 years. I was interested in other methods to make sure I was not missing something. All programmers get stuck in their own ways.

      Not every module started off as a module specific code base and I was interested in how others move code from single use to multiple use as code evolves. That was the point of the post.

        I've also been using Perl since 199cough on and off. I'm not trying to say there is only one way { I've been through Yourdon, SSADM, Agile, TDD and lots of others :-)}, but that if you start off as organised and methodical you won't get to a state where you end up saying "If you want to get to there, I wouldn't start from here" :-)

        If you spot any bugs in my solutions, it's because I've deliberately left them in as an exercise for the reader! :-)
Re: Developing code to be a module
by Old_Gray_Bear (Bishop) on May 01, 2013 at 15:39 UTC
    Well, I am probably not a good example, I have only 'modulized' a couple of time.

    The sequence of events starts with a 'one-shot' the grows up and expands to include several (related) functions of the course of a few weeks/months. At some point I get tired of the spaghetti and spend a weekend writing up functional descriptions (read: the POD and the Examples) and tests for each of the functions.

    Then I spend free time (such as it is) for the next week or two fleshing out the stub-function so that they a) satisfy the spec, and b) pass all the tests. The end result gets installed in my local-lib as a module and I rattle it some more before inflicting it on my Team.

    ----

    I Go Back to Sleep, Now.

    OGB

Re: Developing code to be a module
by talexb (Canon) on May 01, 2013 at 16:39 UTC

    Good question.

    I think about whether the module's going to represent an object, whether it's going to be an API, or whether it's just going to be a collection of useful, related code.

    Once I've figured that out, I can start writing the module, ideally writing tests as I go, so that I have some confidence that new stuff doesn't break the old stuff.

    The three standard modules I start with are strict, warn and Carp, and I always write code with error-checking in place -- that way I never have to remember to add it later.

    And I also use git, committing early and often. I can't tell you how many times way back when I hacked on some code, realized it was a disaster, and longed to go back to an earlier, working version. With git, you can totally do that.

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Re: Developing code to be a module
by Laurent_R (Vicar) on May 01, 2013 at 18:07 UTC

    I have been taking both approaches.

    I have been working on project where I knew that I would have to write 8 to 10 different programs and that all of them would need some common functions. So, in these cases, I wrote the module first with the functions that I needed to share, tested it, and then the programs using these modules. However, despite relatively careful planning, I still had to change the module in the course of writing the programs using them, because I figured out that some more code could be shared between programs. I can remember at least 4 projects where this happened, but there might have been more.

    In other cases, it starts as a couple of function for one program et evolves towards a module. Recently, for example, I wrote my first program in a brand new system. Some of the code was needed more than once, so I made a couple of functions to avoid code duplication. A couple of weeks later, I had to make another program, and I figured out that the same functions would be needed. I copied and pasted the code of the function to deliver this second program quickly (in my opinion, a module needs careful design and should not be made in emergency) and decided that I would take the time to write a module to encapsulate the repeated code for next time. Since then, I have written half a dozen other programs using that module and I have some more to do in the next days. I am quite happy of the fact that I did not have to change the module so far, because I designed in a sufficiently generic way as to work in all cases so far. It would not have been the case if I had settle to write it earlier, before I knew enough about the type of things I would need to do on this new system.

    I think that both approaches have pros and cons.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1031493]
Approved by moritz
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (15)
As of 2014-07-24 20:01 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (166 votes), past polls