|
in reply to The problem of documenting complex modules.
Thanks to everyone who took the time to contribute.
The consensus, such as it is, it that the synopsis should contain a short, clear, complete & correct sample usage, that acts as a working starting point on which to build.
The other idea that (for me) stood out was toolic's suggestion that there could be a Tiny/Simple version of the package that acts as an 'easy in' for the full blown all-singing & dancing version.
Beyond that; the only conclusion I can draw is that good documentation is hard, and not fun, and programmer's are apt to get away with the bare minimum. And often less than that.
My own personal view, unsupported by anyone else who contributed here, is that too much documentation is both a real and prevalent factor; and that automated documentation al la doxygen, javadoc etc. is almost worse than none; as it gives the appearance of 'well documented' with none of the true benefits.
Volume does not equate to good; and comprehensive is perfect for Reference; but it needs a Guide to make it usable.
|
Re^2: The problem of documenting complex modules.(Summation.)
by marioroy (Prior) on Jul 07, 2015 at 16:40 UTC
|
How can a module author express gratitude for this wonderful thread other than saying thank you? This is my favorite thread on PM BrowserUk.
I will merge MCE::Flow and MCE::Loop into MCE::Simple and leave small wrappers to not break existing scripts. I will add MCE::Tutorial and MCE::Cookbook both of which were planned for the upcoming 1.7 release.
By myself, I am clueless on how to solve the duplicity seen in MCE::Flow and MCE::Loop or worst what to call it. Thank you toolic. MCE::Simple is the perfect answer and will help resolve the indecisive storm hovering in my brain.
Thank you all for this.
Mario
| [reply] |
Re^2: The problem of documenting complex modules.(Summation.)
by hippo (Bishop) on Jul 07, 2015 at 22:00 UTC
|
... and that automated documentation al la doxygen, javadoc etc. is almost worse than none; as it gives the appearance of 'well documented' with none of the true benefits.
I could not agree more with this assertion. While such systems have one or two plus points (consistency of presentation, docs always in sync with code) this is usually far outweighed by the complete lack of any semantic meaning to the resulting documentation. There are no reasons given, no caveats, no SSCCEs, no algorithm references. And if/when the code author uses less than meaningful symbol names the whole exercise becomes pointless.
For the particularly complex dists which this thread addresses the resulting volume of brutalist formal data churned out by such auto-documenters is enough to send anyone scurrying for sanctuary. Fine for a reference no doubt, especially to those already well familiar with the dist in question, but not for the neophytes who are only after a gentle concept-based introduction.
| [reply] |
|
|
far outweighed by the complete lack of any semantic meaning to the resulting documentation.
the resulting volume of brutalist formal data churned out by such auto-documenters is enough to send anyone scurrying for sanctuary.
The worst part in my experience is that their use serves as a ready justifiction for not providing anything else.
It's like a car manufacturer supplying dealers with a comprehensive parts list, in place of Workshop manuals.
No other industry would get away with the practice.
| [reply] |
Re^2: The problem of documenting complex modules.(Summation.)
by Anonymous Monk on Jul 07, 2015 at 23:17 UTC
|
I've found even if the docs are overwhelming, or autogenerated, there is still hope most of the time
I skip the documentation and I look for "examples/" and "t/"ests as its code that actually supposed to run :) (also "etc/")
I look for a FizzBuzz HelloWorld type example, clear simple purpose, easy to follow varnames..
If it takes more than three steps its magic ie useless as a foothold
| [reply] |
|
|
I skip the documentation and I look for "examples/" and "t/"ests as its code that actually supposed to run :)
I'd have to need what that module did very, very badly before I'd try to piece together how to use its functionality from a few dozen or hundred ok()/nok() tests.
Reminds me of another module I recently looked at:
- The module pod tells you nothing; just points you at a readme file in a source code tree.
- The readme contains:
- An advert.
I'm already looking, why are you advertising to me?
- Some thankyous to the developers.
If the author works with the devlopers; can't he thank them in person?
- Copyright and license information.
Aren't they traditionally in files called COPYRIGHT and LICENCE?
- A link to a website.
At last; I'm getting somewhere
Buuuuuuut no.
- The website, a triumph of pointlessly oversized graphics and fonts and worshiping at the alter of social media. conceals all the links behind oversized buttons and meaningless text such that you have to click randomly in the hope that you find something that is active.
And when you get to what might be (very) loosely termed, "the documentation" you read:
Software Developers
See step 3 of the INSTALL notes for simple examples, and the `xxxx` command documentation for more information.
Great! A whole website and I've got to go off, download a .tar.gz, unpack it, scrabble around inside to locate a text file called INSTALL; then scrabble around inside that for a subsection of it in order to find the documentation.
This is how they want to encourage me to use their code? Could they have made working out what it is and how to use it more obscure? Perhaps they could have encrypted it all and posted a web treasure hunt to track down the decryption keys al la GCHQ."Starting from www.canyoufind.it.co.uk entrants must hunt down four codes hidden around the world-wide web."
I should coco. I don't care if it is free code, my time is more valuable than that.
| [reply] |
|
|
Great! A whole website and I've got to go off, download a .tar.gz, unpack it, scrabble around inside to locate a text file called INSTALL; then scrabble around inside that for a subsection of it in order to find the documentation.
This is how they want to encourage me to use their code? Could they have made working out what it is and how to use it more obscure? Perhaps they could have encrypted it all and posted a web treasure hunt to track down the decryption keys
Yes, it can get worse: "Community driven documentation", also known as a wiki:
Publish your code, cryptic, uncommented, undocumented. Have your users document it in a wiki. Release early, release often, just to make sure that the sparse information in the wiki is outdated just after it has been posted. Also make sure that the wiki only contains information about the current version, erase all information about older versions.
And to drive users of your code really, really mad: use a forum instead of a wiki, because you don't know how to set up a wiki. Allow every troll, every spammer, every script kiddie to post nonsense. Disable the search function, "coz it killz ma serva". Use robots.txt to keep Google away, because "it killz ma serva, too".
(I've not seen that for Perl modules, but for lots of other software.)
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply]
[d/l] |
|
|
One of the key things I think is that documentation is an opportunity for design. This is why I personally like to do documentation, then coding, then unit testing. But my unit tests are written to the docs, not the code.
If a module doesn't document well, it may not be very useful in a general use case. It may be full of hidden or oblique assumptions, and the author might not have a clear idea why the module is designed the way it is in the first place.
| [reply] |
|
|
|
|
|
|
