I didn't run a POD checker; however, by visual inspection, I see four instances like
C<'escape-unicode'=>1>
Given there are also four, very similar warnings, that you had difficulties identifying,
I'd hazard a guess that they're the source.
I see in your post (to which I'm replying) you've changed one of those to
C<'escape-unicode'=E<gt>1>
You may find it easier, and more readable, to use
C<< 'escape-unicode'=>1 >>
That's explained in "perlpod: Formatting Codes"
(you'll need to scroll down a fair way; it's past all the initial dot points in that section).
I'd also recommend you add this as you first POD command paragraph:
=encoding utf8
That will cover any Greek, or other non-ASCII, examples you may add.
See "perlpod: Command Paragraph: =encoding" for details.
"... do you have an opinion about having function names with params? I don't like it when I read a manual and it mentions only sub names."
Yes, I agree that the arguments should be documented; in addition, the return value should also be described.
I would typically write the example you cite something along these lines:
=head2 C<perl2yaml>
my $yaml = perl2yaml($perlvar, $optional_paramshashref);
The C<perl2yaml> function does ...
Arguments:
=over 4
=item * C<$perlvar>
... C<$perlvar> description ...
=item * C<$optional_paramshashref>
... C<$optional_paramshashref> description ...
=back
Return value:
=over 4
=item * C<$yaml>
... C<$yaml> description ...
=back
Although that looks like a lot of typing for every function,
I'd generally set up a template for all of the formatting:
that only leaves specifics to be entered.
And, where you have very similar documentation, a copy, paste, and substitution can do most of the work;
for instance, you could make three copies of the above then s/yaml/json/g in one copy and
s/yaml/dump/g in another, and most of your work is done
(the three xxxx2perl functions could be handled similarly).
|