Re^2: (How) Do you document/test your private subroutines?

> If it's a function/method which you have found useful/necessary, then other people might find it useful/necessary too, so make it part of your public API

I don't want to expose implementation details which will change in the future
I don't want to clutter the public API with obscure functions
I don't want to have compatibility discussions because I have to rename or drop an internal helper
I don't want the overhead to document something which is just a temporary hack for an early version / proof of concept.

If someone finds a non API function useful after reading the source, he's still free to use it at own risk.

The risk is obvious by the fact that it's NOT part of the public API.

Occasionally I notice that internal functions might be useful for others, in this case outsourcing them to another module appears to be a better strategy.

Cheers Rolf
_{(addicted to the Perl Programming Language :)

Wikisyntax for the Monastery
FootballPerl is like chess, only without the dice}

Comment on Re^2: (How) Do you document/test your private subroutines?


go ahead... be a heretic
	PerlMonks