I'm not going to go into the major aspects as I have not yet written up POD myself, just a couple of minor points.
While it is undeniably gutting to see incorrect usage, the focus of Pod is to inform the user how to implement the module. Refrain from entering ad-hoc didactions about non-related topics.
If I don't know what that funny argument sub {} is, I could always risk asking someone on a forum, or perhaps rtfm. The presentation of the usage should make the argument requirements apparent. If you are going to describe the arguments, consider how consistently you describe them across all the method descriptions. I actually began to look for a hash key 'code' to see what value I would have to provide as an a argument before I realsied you just meant, the first argument is code - how does File::find handle that in Pod?
Introducing a whole new way to do something as second nature as write a paragraph element, could really do with it has it has own description. You may just be reinventing the wheel in a way that people have not considered previously, and it would be a shame to hide this away by muddling it up with the straight forward paragaraph element method. Or it may be a really bad idea, in which case it can be easily ignored or redifined, either way the paragraph separator routine, dare i say it.... needs separating
On another point more along the coding itself, why ask the user to provide the $tab argument for every method? Could you not implement this as default module behaviour, and then describe this in the Pod?
I hope these comments are helpful in your redraftings.
In reply to Re: RFC: Proofread the POD for my HTML elements module
by Don Coyote
in thread RFC: Proofread the POD for my HTML elements module
by Lady_Aleena
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |