Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Module Naming Conventions

by jlongino (Parson)
on Sep 03, 2001 at 06:48 UTC ( #109811=perlquestion: print w/replies, xml ) Need Help??
jlongino has asked for the wisdom of the Perl Monks concerning the following question:

Here I am again, in need of advice. Sometimes I think this project will never end. I suspect that once you begin writing a module it takes on a life of its own. Thanks for all the help so far.

Are there any established module naming conventions? I have a module that I hope will be an enhancement to Term::ReadKey and it has two subs: which for now I'm calling LoadKeyHash, and Keypressed. I had originally wanted to name the module Term::Keypressed but ran into a few error messages that seem to indicate that it wasn't happy with a module being named the same thing as an internal sub. So I've renamed it Term::TermKeys which I think is a more general description of the module (and am happy with now).

Module Term::ReadKey ( also has several subs named ReadKey (the one actually used is determined conditionally and defined via eval) but has several other subs defined within it. Is it more common to name a module after a principal sub, or should it be more descriptive of the purpose/functionally of the module? Am I just splitting hairs here or does any of this matter?

Thanks for any advice/opinions you can provide. I wouldn't be so picky if it were just for my own personal use, but the goal is to make this available for others to use (if it's deemed useful) and possibly a tutorial on it's use as well.

@a=split??,'just lose the ego and get involved!';
for(split??,'afqtw{|~'){print $a[ord($_)-97]}

Replies are listed 'Best First'.
Re: Module Naming Conventions
by footpad (Monsignor) on Sep 03, 2001 at 07:04 UTC

    Perhaps it would be wise to call it "Termkey::Xyzzy" until it's written and then to see what name seems appropriate after you've reviewed the working code?

    After all, until you release it to others, it is for personal use.

    The suggestion isn't a facetious as it sounds. The idea being to get the current problem solved, see what you used to solve it, and then improve those tools when there's some breathing space and experience. Yes, it's nice to know things up front. OTOH, you only get permission to build version 2.0 when the client is satisfied with version 1.0. If this problem is keeping you from getting the work done, then defer it, do the work, and then come back to it. You may find the problem has solved itself by then. If it hasn't, well, at least you haven't wasted your client's and/or sponsor's time on it.


      Apologies for not mentioning, as I did in my previous post Documenting a Module, that the coding aspect is finished. I'm working on the internal perlpod stuff now.

      But useful info anyhow. Thanks.

Re: Module Naming Conventions
by TStanley (Canon) on Sep 03, 2001 at 17:52 UTC
    If you read perlmodlib you will find some answers to your questions

    There's an infinite number of monkeys outside who want to talk to us
    about this script for Hamlet they've worked out
    -- Douglas Adams/Hitchhiker's Guide to the Galaxy

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://109811]
Approved by root
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (5)
As of 2018-03-18 22:19 GMT
Find Nodes?
    Voting Booth?
    When I think of a mole I think of:

    Results (231 votes). Check out past polls.