[Dbix-class] Documentation formatting

Justin Guenther jguenther at gmail.com
Fri Mar 24 20:58:50 CET 2006


On 3/24/06, Andrew Ford <A.Ford at ford-mason.co.uk> wrote:
> A couple of general points on the documentation:
>
> 1. the indent for verbatim text is in many cases too small.  For example
> in the Manual/Example.pod file uses an indent of only one space.  When
> formatted through groff and printed out this results in a typeset indent
> of less than 2mm, which is very hard to read.  The spacing is also used
> literally when man pages are displayed in Emacs.  I would suggest a
> standard indent in the POD of 4 spaces -- it also makes reading the raw
> POD easier than indents of just one or two spaces.

The indent for verbatim text should be 2 spaces, I'll go around fixing
it if it's not. I think 2 spaces is enough to be able to at a glance
discern verbatim text from the descriptions. Comments?

> 2. I would avoid the use of =head3 wherever possible as in pages printed
> through groff these come out as lines set in italic at the sames size as
> the body text (but visually actually lighter and more invisible than the
> body text).  Often one can reduce the number of levels by promoting the
> =head2s to =head1s, so for example "=head2 Installation" in the
> Example.pod becomes "=head1 Installation".  Editorially there is no
> reason why everything needs to go into the Description section (in
> particular for the DBIx::Class::Manual::*.pod files), and the level 1
> headings stand out much more than the lower level headings.

My commit yesterday got rid of every single occurrence of =head3 :) I
do like the current system for header levels though, it seems very
straightforward to me. =head1 for SYNOPSIS, DESCRIPTION etc., and
=head2 for sub-headings.

> 3. With regards the method signatures I prefer pseudo-code.  It is what
> most Perl modules use and visually it is easier to parse than a more
> formal Arguments/Returns layout.  Of course one could have both, e.g.:
>
>     =item $rc = $obj->method($arg1, $arg2)
>
>     =over 4
>
>     =item Arguments:
>
>     =item Returns:
>
>     =back

Most functions have a synopsis given (in all cases I've seen it is
given without an explicit heading)

=head2 function

=over 4

=item Arguments...

=item Returns....

=back

  $schema->function($arg1, $arg2);

Description

Would it look better to have =item $schema->function(...) ?

>
> The problem is that headings like for example "source" (in the
> DBIx::Class::Schema page) do not to my mind leap out as documentation of
> the named method.  I would prefer to see the formatted documentation for
> a method looking something like this:
>
>     $source = $schema->source($name)
>         Returns the result source for the registered name.
>
>
>
> BTW I had also thought about throwing together a quick reference card
> for DBIx::Class for refcards.com.
>
> Regards
> Andrew
>
> --
> Andrew Ford,  Director    Pauntley Prints / Ford & Mason Ltd
> A.Ford at ford-mason.co.uk   South Wing Compton House
> pauntley-prints.co.uk     Compton Green, Redmarley  Tel: +44 1531 829900
> ford-mason.co.uk          Gloucester GL19 3JB       Fax: +44 1531 829901
> refcards.com cronolog.org Great Britain          Mobile: +44 7785 258278
>
>
>
> _______________________________________________
> List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
> Wiki: http://dbix-class.shadowcatsystems.co.uk/
> IRC: irc.perl.org#dbix-class
> SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
>



More information about the Dbix-class mailing list