Re^3: improving the aesthetics of perl code

For subroutine comments, use POD,

I disagree with that. POD is used to make user documentation. Unless you play silly tricks with =for or =begin, anything that you document with POD, will end up in the user manual. That gives you two options:

You will make some subroutines part of the API while they shouldn't be. This breaks encapsulation, and in the future, it will give you the choice to break backwards compatibility, or to support code you'd rather not support. It will restrict your freedom to redo the internals of your module.
Document that the description that follows is about code the user shouldn't use. This makes the documentation clumsy, as it could easily be littered with pieces of documentation the user isn't supposed to use.

POD is for the user, comments are for the coder. And while they may be the same, they usually aren't.

Comment on Re^3: improving the aesthetics of perl code

Replies are listed 'Best First'.
Re^4: improving the aesthetics of perl code by hardburn (Abbot) on Jan 24, 2005 at 18:57 UTC
Why not play tricks with `=for`? It should not be difficult to modify the pod2text converter (or whatever other convert you want) to accept `=for private` blocks. Then you can have two converters, one for basic API information, and another for private docs. Javadocs have a similar concept, and I think it's a good idea. Getting your developers to follow it is simply a matter of corporate coding policy. In fact, I think I should probably implement that, or track down a converter that does it already. "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^4: improving the aesthetics of perl code
by hardburn (Abbot) on Jan 24, 2005 at 18:57 UTC

Why not play tricks with =for? It should not be difficult to modify the pod2text converter (or whatever other convert you want) to accept =for private blocks. Then you can have two converters, one for basic API information, and another for private docs. Javadocs have a similar concept, and I think it's a good idea. Getting your developers to follow it is simply a matter of corporate coding policy.

In fact, I think I should probably implement that, or track down a converter that does it already.

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

[reply]
[d/l]
[select]