in reply to Deriving meaning from source code, some code is self documenting

You may want to add the other common idioms for making a subclass: our @ISA qw(My::Class); and use parent qw(My::Class);. All of these are listed in the Exporter docs, as recommended.

Oh, and while you're at it... :) The other 'automatic' bit of POD I'd often like to see is a list of dependencies: Anything that is use'd in the code.

(By my giving you more things to add into your project you can tell I think it is a good one. ;) )

Replies are listed 'Best First'.
Re^2: Deriving meaning from source code, some code is self documenting
by submersible_toaster (Chaplain) on Dec 08, 2008 at 14:29 UTC

    excellent thankyou! While I'm there , why not markup functions with prototypes , note subs resembling methods, snarf attributes. It's rich ground for 'features' :)


    I can't believe it's not psellchecked

      Ah, but at least in most of those cases the programmer would still have to write something to describe the data you are pulling out: The bare data itself isn't all that useful. (What does it mean?)

      Whereas the inheritance and dependencies are useful even (or especially) when simply listed. So at least there's a reason for drawing a line there. ;)

        True, but you might be able to get *something* from the variable names. e.g.
        sub foo { my ($needle, @haystack) = @_; ... }
        Having those available might be useful (of course you can read the source as well, but you might want to see that from a different module).

        This is exactly the sort of specificity that a plugin would grab. Macropod::Parser::Include::signatures would be loaded by Macropod::Parser::Include plugin , and passed the in play ppi statement which might be use signatures along with the whole PPI source document and the in play Macropod::Document. Hopefully being pluggable in this way permits someone with specialist interest to handle just their special cases.


        I can't believe it's not psellchecked