@FaheemMitha Documentation should not be generated from comments. Comments in code is for giving clarification to code, and extracting them would render them void of the context that they belong in.
Java doc etc. is just a way to insert documentation into code. That's basically a decision to keep the documentation close to the code it's documenting, nothing else. Again, it's different from comments in code (i.e. the purpose of the text is different).
I find literate programming very useful for documenting why the code is as it is (as well as for structuring code). It doesn’t help much with writing docs for how to use the abstractions provided by the code.
And people writing code tend to not be that great at documenting how to use it :-/.
IME the best approach to getting good documentation and APIs, is to write the documentation first, then write the interfaces, then write the tests, and last, write the implementation.
The best user documentation would probably be that written by the users. But it's hard to get users to write documentation. Once they know how to use it, they're not interested any more.
For example, Debian bug reports tend to be quite good. Why? Because Debian users are technical.
@MichaelHomer Most programmers, and even sysadmins, do a fair amount of writing, one way of the other. If only in reports.
And that assumes they haven't gone to the usual liberal arts education thing, where they have to write essays and stuff. Though that might be more an American thing.
@FaheemMitha someone who makes a piece of software understandable for users
That involves knowing what users want to do, understanding enough of the system to be able to massage the developers’ explanations and ignore the stuff they care about which doesn’t matter to the user...
A technical writer is a professional information communicator whose task is to transfer information (knowledge) between two or more parties, through any medium that best facilitates the transfer and comprehension of the information. Technical writers research and create information through a variety of delivery mediums (electronic, printed, audio-visual and even touch). Example types of information include online help, manuals, white papers, design specifications, project plans, software test plans, etc. With the rise of e-learning, technical writers are increasingly becoming involved with creating...
@FaheemMitha they write documentation for whoever the target audience is. In most companies which pay for technical writing, that’s end users; end users don’t care much for what I think of as technical documentation.
Like those software manuals that nobody can understand because they assume an intimate and expert knowledge of the software. Which is, frankly, maddening. Though I know such people do mean well.
And some documentation is better than none.
@StephenKitt No, I've never had that job title. Though I've certainly written documentation. And I don't think it's as hard as you're making it sound. Of course, it's not trivial either.
But really, I'm thinking more about stuff like manuals for a software library. Not something like MS Word. Which I agree is not really the same sort of thing.
@FaheemMitha you’re saying anyone can do it, I’m saying that not anyone can do it; I’m not saying it’s outlandlishly difficult. However most people who think they can write docs, write poor docs.
@StephenKitt No, I'm definitely not saying anyone can do it. Sorry if I gave that impression.
But it doesn't require an "expert" either. Whatever that might be.
For example, the GNU documentation is generally good. Why? Not because the authors were super-talented technical writers, but because the project historically considered documentation important, possibly taking their lead from Richard Stallman, and fostered a culture that cared about such things.
Often technical documentation is very poor. E.g. the R help pages are ridiculous. (I don't mean to pick on R, it's just an example that comes to mind.)
And it's because they are not particularly thinking of the user side of the picture.
And the R devs are not receptive to constructive criticism. I did try once, I think. Perhaps I didn't do a good job of expressing myself.
@Fabby thanks for the pointers. I might end up doing that.
I also comment classes with a description of what their objective is and how they achieve it. Every method/function has comments describing what it does, why, parameters, returned values. I also comment unclear parts of methods/functions.
Shit is about to get real in the office.
We have a ping pong table, and yesterday me and a buddy were gonna chill for a couple minutes and play. There was no ping pong ball though.
Right now a couple cybersecurity interns are playing ping pong. The little bastards have been taking the ping pong ball with them when they finish playing....not sure how to get my revenge....
@JeffSchaller You're evil... But funny as hell! :-)
CC @Ungeheuer I agree with Jeff: fill their cubicles with ping pong balls or if that'll be frowned upon, at least their unlocked drawers, shelves, chair, ...
They're SecOps, right? They should have locked them anyway...
@StephenKitt I was wondering how you write the documentation, any standard to follow, or just personal style? What-driven development is doc->interface->test->implementation called?
@MichaelHomer I can't understand the explanations of monad in terms of the functional languages. They are supposedly easier to understand than the categorical definition, but I haven't managed to see that.
@MichaelHomer Scala borrows a lot of features from several languages of different paradigms and even within the same FP paradigm. I guess that makes it harder to understand well than some languages it borrows from, when one doesn't feel easy to separate and group the features.
The RHEL7 NFS guide access.redhat.com/documentation/en-us/red_hat_enterprise_linux/… mentions /etc/sysconfig/nfs not /etc/nfs.conf, however, the nfs manpage doesn't make reference the former, and there exists a manpage for the latter file. Which one should I be using? They are both configuration files for the server and configure the same things. I don't think it matters in terms of functionality, but I care about best practice.